Scalable architecture

ABSTRACT

Exemplary embodiments may employ techniques for dynamically dispatching requests to resources operating in a distributed computing environment, such as a computing cloud, according to one or more policies. Embodiments may further dynamically adjust resources in the computing environment using predictive models that use current loads as an input. Embodiments may still further maintain a state for a processing environment independent of the type or configuration of a device used to access the environment on behalf of a user.

RELATED APPLICATIONS

The instant patent application is a continuation of U.S. patentapplication Ser. No. 13/485,836, filed May 31, 2012 (now U.S. Pat. No.8,918,511) which is a divisional application of U.S. patent applicationSer. No. 12/651,284, filed Dec. 31, 2009 (now U.S. Pat. No. 8,380,880),which is a continuation-in-part application of U.S. patent applicationSer. No. 12/021,856, filed Jan. 29, 2008, which claims priority to U.S.Provisional Patent Application No. 60/899,228, filed on Feb. 2, 2007,the contents of which are incorporated herein by reference in theirentirety.

BACKGROUND INFORMATION

Computing applications may be used in technical disciplines, such asmathematics, engineering, physical sciences, medicine, etc., to solvetechnical problems. For example, these applications may be used to findsolutions to problems that describe a physical system (e.g., a controlsystem) and may display results for the solutions. These computingapplications can be operated in standalone environments, where theapplication is installed and run on a local computer, such as a desktopcomputer operated by a user.

Some users may find that standalone environments are unsatisfactory whenattempting to solve complex problems. For example, standaloneenvironments may be unsatisfactory because of memory limitations (e.g.,inadequate memory), processing limitations (e.g., insufficientprocessing power and/or processing architectures that cannot be scaledto adequately handle complex processing tasks), display limitations(e.g., unsatisfactory display hardware), outdated software (e.g.,processing software that is not up-to-date), etc. Attempting to work oncomplex processing tasks, such as processing tasks for solving technicalproblems, using standalone environments may produce system crashes,unacceptably long processing times, inferior display resolution, and/orerroneous results.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more embodiments of theinvention and, together with the description, explain the invention. Inthe drawings,

FIG. 1 illustrates an exemplary system that can be configured topractice an exemplary embodiment;

FIG. 2 illustrates an exemplary system that can be used to performnetwork-based technical computing;

FIG. 3A illustrates an exemplary system that can include multipleclients and/or servers;

FIG. 3B illustrates an exemplary system that can include a database forstoring information related to network-based technical computing;

FIG. 3C illustrates an exemplary system that can include a farm managerto interact with multiple technical computing environments that performtechnical computing operations;

FIG. 4 illustrates exemplary messaging that can be used to supportnetwork-based technical computing;

FIG. 5 illustrates an exemplary system that can include one or more datacenters;

FIG. 6 illustrates an exemplary system that can include multiple serviceproviders;

FIG. 7 illustrates an exemplary functional diagram that includes logicthat can be used to implement a server;

FIG. 8 illustrates an exemplary data structure that can storeinformation about operations performed by a server;

FIGS. 9A-9C illustrate exemplary user interfaces that can be displayedon a client;

FIG. 10 illustrates exemplary processing performed by a client;

FIG. 11 illustrates exemplary processing performed by a server;

FIG. 12 illustrates exemplary processing performed by a server;

FIGS. 13A-13E illustrate exemplary embodiments that can perform remoteprocessing operations on behalf of a client.

FIG. 14 illustrates an embodiment that implements a quick commandservice;

FIGS. 15A and 15B illustrate exemplary user interfaces that can be usedwith a quick command service;

FIG. 16A illustrates an exemplary setup window;

FIG. 16B illustrates an exemplary results window;

FIG. 17A illustrates an exemplary revision comparison window;

FIGS. 17B and 17C illustrate an exemplary results window;

FIG. 18 illustrates an exemplary user interface for configuring a remoteprocessing application;

FIG. 19 illustrates an exemplary system for monitoring softwareapplication usage;

FIG. 20 illustrates an exemplary user interface for monitoring softwareapplication usage;

FIG. 21 illustrates an exemplary user interface for monitoring softwareapplication usage for a device;

FIG. 22 illustrates an exemplary system for publishing code forperforming technical computing operations;

FIG. 23 illustrates an exemplary user interface for interacting withcode;

FIG. 24 illustrates an exemplary user interface for interacting withpublished code (e.g., to enter a first input);

FIG. 25 illustrates an exemplary result produced by running publishedcode (e.g., code run in response to the first input);

FIG. 26 illustrates an exemplary user interface for interacting withpublished code (e.g., to enter a second input);

FIG. 27 illustrates an exemplary result produced by running publishedcode (e.g., code run in response to the second input);

FIG. 28 illustrates an exemplary computing architecture that can be usedto implement a client or a server;

FIG. 29 illustrates an exemplary system for implementing an embodimentof the invention;

FIG. 30 illustrates exemplary processing for dispatching processingrequests to distributed processing resources using an embodiment of theinvention;

FIG. 31 illustrates exemplary processing for proactively providingremote processing resources using an embodiment of the invention;

FIG. 32 illustrates an arrangement of software modules that can be usedperform the exemplary processing illustrated in FIG. 31;

FIG. 33 illustrates exemplary processing for maintaining state for anenvironment when the environment is accessed via a remote device.

DETAILED DESCRIPTION

The following detailed description of implementations consistent withprinciples of the invention refers to the accompanying drawings. Thesame reference numbers in different drawings may identify the same orsimilar elements. Also, the following detailed description does notlimit the invention. Instead, the scope of the invention is defined bythe appended claims and their equivalents.

Overview

Previously known computing applications may be inadequate for solvingcertain types of problems, such as technical problems that can beencountered in the fields of science, engineering, medicine, economics,etc. For example, a conventional computing application may performprocessing operations using a single device (e.g., a client device)operating in a standalone environment, where the single device may ormay not support an environment that adequately solves certain technicalproblems (e.g., complex technical problems). Alternatively, the clientdevice may attempt to remotely perform technical processing operationson a single server over a network. In certain situations, the singleserver may not support an environment that adequately solves technicalproblems on behalf of the client device. Inadequate processing resourcesmay lead to unacceptably long processing times. Alternatively,inadequate processing resources may not allow certain types ofprocessing tasks to be performed (e.g., tasks that include large and/orcomplex computations).

Exemplary embodiments may alleviate problems associated withconventional computing applications by providing a scalable remoteprocessing architecture that can be adapted to efficiently solvesubstantially any type of problem (e.g., large and/or complex technicalcomputing problems). For example, an embodiment may use remoteprocessing code that allows a client device to make use of one or moreremote processing resources provided over a network, such as theInternet. In one embodiment, the client may download the remoteprocessing code from one or more servers, and in another embodiment theclient may run the remote processing code remotely on one or moreservers via a web service.

Remote processing, as used herein, refers to substantially any type ofprocessing that is remote with respect to a requesting device. Therequesting device may be a client device. For example, remote processingcan include distributed processing where a number of devices performprocessing on behalf of a requesting device. Remote processing canfurther be performed on one or more processing devices that can beembodied in hardware based logic and/or software based logic. Forexample, remote processing can be performed on microprocessors,clusters, labs, etc. Remote processing may further be performed over anetwork, a direct connection (e.g., a link, bus, cable, etc.), etc.

Remote processing code may adaptively select one or more remoteprocessing resources based on client defined parameters or based onparameters defined by another device, such as a server operated by aservice provider. For example, the remote processing code may selectprocessing resources based on availability of the resources, based on ascaled pricing structure (e.g., where the client can use additionalprocessors simultaneously for a larger fee), based on the type ofproblem being solved (e.g., a complex simulation application may usemore processors as compared to the number of processors that a lesscomplex simulation application uses), based on a priority associatedwith the client, based on a time of day (e.g., a client performingprocessing during non-peak hours may get more processing resources thana comparable client that performs processing during peak-hours), etc.

Remote processing resources (e.g., devices) operating on behalf of theclient may operate in a number of configurations. For example, aprocessing resource may be embodied as a unit of execution, where a unitof execution can be a hardware-based or software-based entity thatperforms processing on behalf of a client. Units of execution can beimplemented as single entities (e.g., a single processor) or as multipleentities (e.g. multiple processors). A client may use one or more unitsof execution to perform processing operations on its behalf. In anotherembodiment, two or more units of execution may be arranged in clusterson a network and a client may use one, two, or more clusters to performprocessing operations on its behalf. Exemplary embodiments may switchunits of execution and/or clusters into or out of processing operationsfor a client according to a schedule and/or based on other parameters(e.g. complexity of a problem, a priority assigned to the client, etc.).

Assume, for sake of example, that a user has a 100×100 array that needsto be processed. The user may send the array to a server for remoteprocessing. The server may determine that each column or row should beprocessed on a separate unit of execution when at least 100 units ofexecution are available. The server may parse the array into columns orrows and may send one column/row to each of 100 units of execution. The100 units of execution may process the columns/rows substantiallysimultaneously and may send results back to the server. Alternatively,the server may determine that only ten units of execution are availableto operate on the array. The server may send one-tenth of the array toeach unit of execution and the ten units of execution may operate on thearray portions substantially simultaneously to produce ten results thatare sent back to the server. In yet another embodiment, the server maysplit the array into unequal sections and distribute those sections tounits of execution for processing. Still other implementations mayprocess the array in other ways using a number of units of execution.

Exemplary embodiments may perform remote processing on behalf of one ormore clients in serial or in parallel. Determinations about processing aparticular problem (e.g., serial, parallel, etc.) may be made accordingto client determined parameters and/or according to other parameters.For example, a server may retrieve resource parameters (e.g., unit ofexecution availability information) and may use the retrieved parametersto determine how to process the problem.

As used herein, parallel processing can refer to task parallelprocessing, data parallel processing, and/or stream parallel processing.Task parallel processing may refer to parallel processing where a numberof tasks are processed at substantially the same time on a number ofprocessing resources. In task parallel processing each task may beprocessed independently of other tasks executing at the same time (e.g.,a first processor executing a first task may not communicate with asecond processor executing a second task).

In another embodiment, parallel processing may refer to data parallelprocessing, where data (e.g., a data set) is parsed into a number ofportions that are executed in parallel using two or more processingresources. In data parallel processing, processing devices and/or dataportions may communicate with each other as processing progresses.

In still another embodiment, parallel processing may refer to streamparallel processing (also referred to as pipeline parallel processing).Stream parallel processing may use a number of processing resourcesarranged in series (e.g., a line) where a first processor produces afirst result that is fed to a second processor that produces a secondresult. Stream parallel processing may be prevalent in certain fields,such as signal processing, image processing, etc.

Other embodiments may combine two or more of task, data, or streamparallel processing techniques alone or with other types of processingtechniques to form hybrid-processing techniques without departing fromthe spirit of the invention.

Exemplary embodiments may include a hardware infrastructure that allowsa number of services to be offered to a client. For example, a remoteprocessing hardware configuration may allow services to be modularlydeployed to a client. In one embodiment, a client can be provided withone or more services that can include a collaborative service (e.g.,collaborative coding service, etc.), a competition service (e.g., acoding competition service, etc.), a testing service (e.g., code testingservice, real-time testing service, etc.), a remote processing service(e.g., distributed processing service, parallel processing service,serial processing service, etc.) a pre-computing service (e.g., aconstant pre-computing service, an eigenvalue pre-computing service,etc.), an analysis service (e.g., a data analysis service, etc.), a gameservice (e.g., coding game service, video game service, text gameservice, etc.), a puzzle service (e.g., coding puzzles), etc. Theseservices may be offered to the client on a subscription basis, a per usebasis, free of charge, in exchange for information, products, services,etc., received from the client, etc.

Exemplary Systems

FIG. 1 illustrates an exemplary system 100 that can be configured topractice an exemplary embodiment. System 100 may include client 110,network 120, server 130 and service provider 140. The embodiment of FIG.1 and/or embodiments shown in other figures included herein areexemplary and other embodiments may include more devices or acts (e.g.,processing acts illustrated in flowcharts), fewer devices or acts,and/or devices/acts in arrangements other than the arrangements shown inthe figures included herein.

Client 110 may include a device that sends data to or receives data fromanother device, such as server 130. “Data,” as used herein, may refer toany type of machine-readable information having substantially any formatthat may be adapted for use in one or more networks, devices,applications, etc. Data may include digital information or analoginformation. Data may further be packetized and/or non-packetized.

In an embodiment, client 110 may be a computer, such as a desktopcomputer, a laptop computer, a client, a server, a mainframe, a personaldigital assistant (PDA), a web-enabled cellular telephone, a smartphone, smart sensor/actuator, or another computation or communicationdevice that executes instructions to perform one or more activitiesand/or generate one or more results.

Network 120 may include a network that transfers data (e.g., packet dataor non-packet data). Implementations of network 120 may include localarea networks (LANs), metropolitan area networks (MANs) and/or wide areanetworks (WANs), such as the Internet, that may operate usingsubstantially any network protocol, such as Internet protocol (IP),asynchronous transfer mode (ATM), synchronous optical network (SONET),user datagram protocol (UDP), IEEE 802.11, etc.

Network 120 may further include network devices, such as routers,switches, firewalls, and/or servers (not shown). Network 120 may be ahardwired network using wired conductors and/or optical fibers and/ormay be a wireless network using free-space optical, radio frequency(RF), and/or acoustic transmission paths. In one implementation, network120 may be a substantially open public network, such as the Internet. Inanother implementation, network 120 may be a more restricted network,such as a corporate virtual network. Implementations of networks and/ordevices operating on networks described herein are not limited to anyparticular data type, protocol, architecture/configuration, etc. Forexample, in one embodiment, network 120 may be a quantum network thatuses quantum-compatible networking protocols.

Server 130 may include a device that receives data from, and sends datato, another device and/or network. For example, server 130 may includeone or more server devices/computers (e.g., a workstation, mainframe,desktop computer, laptop computer, PDA, web enabled cellular telephone,smart phone, Wi-Fi device, smart sensor/actuator, or another type ofdevice).

Implementations of server 130, and/or other devices in system 100, caninclude substantially any type of computing architecture/components,such as silicon-based components and/or supporting architectures,quantum-based components and/or supporting architectures, optical-basedcomponents and/or supporting architectures, etc. Server 130 may beimplemented as a standalone device, a distributed arrangement of devices(e.g., a cluster or pool of devices) arranged in substantially any typeof configuration (e.g., star, ring, grid, etc.). Distributedimplementations of server 130 may further include devices, such as loadbalancers, network devices, etc., to allow distributed implementationsof server 130 to operate in a determined manner.

In one implementation, server 130 may provide a service to other devicesin system 100, such as client 110. For example, server 130 may provideremote processing services to client 110 via network 120. In anembodiment, server 130 may send code to client 110, and client 110 mayinstall and run the code to perform remote processing operations usingserver 130. In another embodiment, client 110 may perform remoteprocessing operations using code that operates on server 130. In thisembodiment, server 130 may send results, such as display data, to client110. In another embodiment, client 110 may operate in a hybridconfiguration. In a hybrid configuration, client 110 may download aportion of the remote processing code from server 130 and may also usecode that remains on server 130 when performing remote processingoperations.

Service provider 140 may include a device that makes a service availableto another device. For example, service provider 140 may include anentity (e.g., an individual, a corporation, an educational institution,a government agency, etc.) that provides one or more services to adestination using server 130 and/or other devices. Services may includeinstructions that are executed by a destination to perform an operation.Alternatively, a service may include instructions that are executed toperform an operation on behalf of a destination.

Assume, for sake of example, that a telecommunications provider operatesa web server that provides one or more web-based services to adestination, such as client 110. The web-based services may allow client110 to perform remote processing using hardware that is operated by thetelecommunications provider (e.g., server 130). For example, client 110may use service provider hardware to perform remote processing whenclient 110 subscribes to the offered web service. In one implementation,a customer (e.g., client 110) may receive services on a subscriptionbasis. A subscription may include substantially any type of arrangement,such as monthly subscription, a per-use fee, a fee based on an amount ofinformation exchanged between service provider 140 and the customer, afee based on a number of processor cycles used by the customer, a feebased on a number of processors used by the customer, etc.

FIG. 2 illustrates an exemplary system that can be used to performnetwork-based technical computing. System 200 may include client 110,network 120, server 130, service provider 140, display 210, browser 220,web client 230, servlet 240, web service 250, LAN 260, unit of execution(UE) 270, engine socket 280, and technical computing environment (TCE)290.

Display 210 may include a device that renders information to a user,such as a user of client 110. Display 210 may include a cathode ray tube(CRT) device, a liquid crystal display (LCD) device, a plasma displaydevice, a projection based display device (e.g., digital lightprojection (DLP)), a touch sensitive display device, etc. Display 210may display text and/or graphics to a user based on instructionsassociated with client 110, server 130, or another device, such asanother device on network 120 (not shown in FIG. 2). In one embodiment,display 210 may display a web browser 220 to a user. Browser 220 mayinclude logic that displays text and/or graphics to a user and/or thatmay execute code (e.g., applets, plug-ins, etc.). Embodiments of browser220 can include any type of application that allows a user to accessinformation on a remote server, such as a Unix wget command, an filetransfer protocol (ftp) client, an email client, etc.

Web client 230 may include logic operating on client 110 that makes useof a web service, such as web service 250. In one embodiment, web client230 may display browser 220 on display 210. Web client 230 may alsointeract with web services that provide remote processing capabilitiesto client 110. Web client 230 may communicate with server 130 usingsecure connections (e.g., via using secure socket layer) and/or insecureconnections.

In an embodiment, web client 230 may operate within a virtual machine,such as asynchronous JavaScript and extensible markup language (AJAX),Flash by Macromedia (now Adobe), Java virtual machine, etc. A virtualmachine may refer to running multiple instances of code that run on ahost computer but behave as if the code instances were running onseparate host computers. For example, server 130 may run multipleinstances of a virtual operating system where each instance of a virtualoperating system operates independently of another instance of a virtualoperation system on server 130. Virtual machines can operate inhierarchies (e.g., one virtual machine can operate within anothervirtual machine) or in parallel.

Server 130 may include servlet 240 and web service 250. Servlet 240 mayinclude code that receives a request and returns a response. Forexample, servlet 240 may receive a request from web client 230 and mayreturn a response that includes text, images, instructions, etc. In oneembodiment, servlet 240 may receive multiple requests and may generatemultiple responses that can be grouped in, for example, one or moresessions.

Web service 250 may include logic that supports machine-to-machineinteractions over network 120. For example, web service 250 may includecode that makes one or more remote processing services available toclient 110. By way of example, a first web service may send code toclient 110, and client 110 may execute the code to use distributedprocessors that perform remote processing operations. A second webservice may display information on client 110 using a browser and mayreceive remote processing requests from client 110. The second webservice may execute the requests on behalf of client 110 and may sendremote processing results to client 110.

Web service 250 may include software, such as one or more applicationprogram interfaces (APIs), for sending information to and for receivinginformation from a destination, e.g., client 110. In one embodiment, webservice 250 may communicate with client 110 using one or more standards,such as simple object access protocol (SOAP). Web service 250 mayfurther use a type of message, such as hypertext markup language (HTML),extensible markup language (XML), etc., when communicating with client110. Embodiments of web service 250 may expose TCE 290 to client 110 sothat client 110 can perform remote processing or computing operationsover network 120 and/or LAN 260.

LAN 260 may include a private network that allows server 130 to securelycommunicate with one or more UEs 270. Other embodiments of LAN 260 maybe configured in other ways (e.g., as an open network).

UE 270 may include logic that performs processing activities on behalfof another device. Embodiments of UE 270 may be hardware based (e.g., ahardware unit of execution), software based (e.g., a software unit ofexecution), and/or based on a combination of hardware and software. Forexample, in one embodiment UE 270 may perform remote processing onbehalf of client 110 using a single processing device. In anotherembodiment, UE 270 may perform remote processing (e.g., parallelprocessing) on behalf of client 110 using two or more processors, cores,etc. Implementations of UE 270 may perform remote processing in a numberof ways, such as by performing remote processing activities related totask parallel processing, data parallel processing, stream parallelprocessing, etc. Implementations of UE 270 may be configured insubstantially any manner. For example, a first UE may include a copy ofTCE 290 and a second UE may not include a copy of TCE 290.

UE 270 may perform unidirectional communication with server 130 and/orclient 110 and/or may perform bi-directional communication with server130 and/or client 110. In unidirectional communication, UE 270 mayreceive a command and send a result to server 130 or client 110. Incontrast, bidirectional communication may allow UE 270 to perform robusttwo way communication with server 130 and/or client 110. For example, UE270 may send a request to server 130 for code, additional memory space,additional processing resources, etc. Alternatively, UE 270 may makeremote display requests to client 110 to allow UE 270 to operate adisplay device on client 110. Bidirectional communication between arequesting device and a UE is described in co-pending application Ser.No. 11/706,805 entitled “Bi-directional Communication In A ParallelProcessing Environment,” filed: Feb. 14, 2007, the contents of which areincorporated herein by reference in their entirety. UE 270 may beidentified using a parameter, such as a parameter that indicates that UE270 is available to perform remote processing on behalf of server 130and/or another device. In other embodiments, UE 270 may be identifiedusing other techniques.

Engine socket 280 may include logic that operates as the endpoint of acommunication link, such as a bi-directional communication link. In oneembodiment, server 130 may include an engine socket (not shown in FIG.2) that communicates with engine socket 280 on UE 270. Engine socket 280may support encrypted or non-encrypted exchanges with server 130.Embodiments of engine socket 280 may be implemented in hardware basedlogic and/or software.

Technical computing environment (TCE) 290 may include hardware and/orsoftware based logic that provides a computing environment that allowsusers to perform tasks related to disciplines, such as, but not limitedto, mathematics, science, engineering, medicine, business, etc., moreefficiently than if the tasks were performed in another type ofcomputing environment, such as an environment that requires the user todevelop code in a conventional programming language, such as C++, C,Fortran, Pascal, etc. In an alternative embodiment, TCE 290 may be usedto execute tasks not formally related to conventional technicaldisciplines, but still requiring execution of computations.

In one implementation, TCE 290 may include a dynamically typed language(e.g., a dynamically typed programming language) that can be used toexpress problems and/or solutions in mathematical notations familiar tothose of skill in the relevant arts. For example, TCE 290 may use anarray as a basic element, where the array may not require dimensioning.In addition, TCE 290 may be adapted to perform matrix and/or vectorformulations that can be used for data analysis, data visualization,application development, simulation, modeling, algorithm development,etc. These matrix and/or vector formulations may be used in many areas,such as statistics, finance, image processing, signal processing,control design, life sciences, education, discrete event analysis and/ordesign, state based analysis and/or design, etc.

TCE 290 may further provide mathematical functions and/or graphicaltools (e.g., for creating plots, surfaces, images, volumetricrepresentations, etc.). In one implementation, TCE 290 may provide thesefunctions and/or tools using toolboxes (e.g., toolboxes for signalprocessing, image processing, data plotting, parallel processing, etc.).In another implementation, TCE 290 may provide these functions as blocksets. In still another implementation, TCE 290 may provide thesefunctions in another way, such as via a library, etc. TCE 290 may beimplemented as a text based environment, a graphically basedenvironment, or another type of environment, such as a hybridenvironment that is both text and graphically based.

FIG. 3A illustrates an exemplary system that can include multipleclients and/or servers. System 300 may include a number of clients 110-1to 110-N (collectively clients 110), network 120, a number of servers130-1 to 130-N (collectively servers 130), service provider 140, anumber of UEs 270-1 to 270-N (collectively UEs 270), load balancer 310,farm manager 320, cluster 330 and cluster 330-1 (collectively clusters330).

Clients 110 can include a number of computers operated by acorresponding number of users or by a number of users that differs froma number of computers. Clients 110 may be related to each other, such ascomputers used by employees of a corporation, or may be unrelated toeach other, such as residential computers operating in a number ofhouseholds.

Network 120 may include one or more load balancers 310 to balanceoperational loads on network 120 and/or devices operating with network120, such as servers 130. For example, a number of clients 110 mayattempt to access TCEs 290 at substantially the same time using network120. Logic in network 120, such as load balancer 310, may identifydestinations being contacted, types of processing being sought byclients 110, etc., and may route certain clients to certain destinationresources, such as servers 130. For example, load balancer 310 may routeclient 110-1 and client 110-3 to server 130-2 and may route client 110-2to server 130-N. In alternative embodiments, load balancer 310 may belocated elsewhere in system 300 and/or load balancing functionality maybe incorporated into other devices, such as server 130, UE 270, farmmanager 320, etc.

Servers 130 may operate with farm manager 320 when operating on requestsfrom clients 110. For example, servers 130 may include web servers thatinteract with browsers 220 operating on clients 110. Servers 130 may, ormay not, include actual processing hardware that is used to performcomputations, such as technical computations, on behalf of clients 110.Servers 130 may use a device, such as farm manager 320, to select ordeselect processing resources in a manner that provides at least asubset of clients 110 with desired levels of performance (e.g., withdesired processing times, accuracies, pricing, etc.).

Farm manager 320 may include a device that maintains information about anumber of processing resources and that uses the information to selectprocessing resources on behalf of a requesting device. For example, farmmanager 320 may include a server that maintains information about anumber of UEs 270 that perform processing operations on behalf of arequesting device. Farm manager 320 may select one or more processingresources based on determined criteria, such as complexity of a problem,a type of processing problem, a determined processing interval, aprocessing cost, etc. Farm manager 320 may be configured to manageprocessing resources statically (e.g., according to fixed criteria)and/or dynamically (e.g., according to changing criteria, such asnetwork loading, processing complexity, priorities, etc.).

UEs 270 and/or other devices can be arranged in groups, such as clusters330, in one or more exemplary embodiments. Clusters 330 may allowresources to be managed in efficient ways as compared to resourcesmanaged without clusters 330. For example, it may be determined thatgrouping certain UEs 270 into clusters will enhance processing servicesprovided to customers. In one embodiment, UEs 270-3, 270-4, and 270-5may be grouped into cluster 330 because these UEs may include aspecialized hardware/software configuration that allows a certain typeof problem to be more efficiently processed in parallel among the UEs ofcluster 330 than if the problem were processed by devices not arrangedin a cluster. In this embodiment, it may further be determined thatother UEs should operate individually, such as UE 270-1 and UE 270-2.

Clusters 330 may be formed according to substantially any type ofcriteria, such as a type of problem to solve, a fee charged tocustomers, an anticipated processing load or network load, a particularhardware or software configuration, a scalability parameter, anoperational redundancy parameter, a processing latency value, ageographic configuration, etc.

Servers 130, UEs 270, farm manager 320, and/or clusters 330 may beoperated by an entity, such as service provider 140 in an exemplaryembodiment. In other embodiments, servers 130, UEs 270, farm manager320, and/or clusters 330 may be operated by a number of separateentities.

FIG. 3B illustrates an exemplary system 302 that can include a database335 for storing information related to network-based technicalcomputing. System 302 may be configured similar to system 300 and mayfurther include database 335. Database 335 may include logic that storesinformation on behalf of another device, such as servers 130 and/or farmmanager 320. For example, database 335 may include an array of storagedevices that store information used by devices operated by serviceprovider 140.

An embodiment of database 335 may store user information, revisioncontrol information, and resource information. Other embodiments ofdatabase 335 may store other types of information. User information mayinclude user identifiers, passwords, privileges, account information,code (e.g., simulation, modeling, analysis, etc., software),configuration information (e.g., hardware preferences), etc.

Revision control information may include revision identifiers, revisiondates, size information, etc. For example, revision control informationmay include identifiers for particular versions of TCE 290 that operateon certain UEs 270. Revision control information may further includeinformation that identifies differences between versions/releases ofhardware or software operating in system 302, such as differencesbetween versions/releases of TCEs 290, UEs 270, servers 130, etc.

Resource information may include identifiers for resources in system302. For example, resource information may identify available UEs 270that can be used to operate on a task submitted by client 110.Embodiments of database 335 may allow processing resources (e.g., UEs270 and/or clusters 330) to be managed cost effectively as compared tomanaging resources without database 335. Resource information may bestatic or dynamic depending on configurations of system 302.

Information in database 335 may be used for many purposes, such as forgenerating reports. For example, service provider 140 can generatereports for users that identify types of processing performed, number ofUE processing cycles used, remote processing costs, etc. Information indatabase 335 may be processed using, for example, an anonymizer toremove user identifiers so that information about system 302 can be madeavailable to a destination without identifying a source from which thedata was gathered. Information in database 335 may further be used togather statistical information about devices in system 302. Statisticalinformation can be used to identify development areas for serviceprovider 140, to identify hardware purchases, to configure loadbalancing devices, etc.

FIG. 3C illustrates an exemplary system 304 that can include a farmmanager that interacts with multiple technical computing environmentsthat perform technical computing operations. System 304 may include aservice provider 140 that includes one or more enclosures 355-1 to 355-N(collectively enclosures 355). Enclosures 355 may include hardwareand/or software used to implement functionality associated with servers130.

In one embodiment, enclosure 355 may include host computer 340A,application server 345 and TCE servlet 350. Host computer 340A mayinclude logic that provides an operating system that supports serverfunctionality, such as web serving, database read/write operations, userauthentication, billing, etc. Host computer 340A may include logic basedon open standards/specifications (e.g., UNIX) and/or proprietarystandards/specifications.

Application server 345 may include logic that serves content, such asweb pages, to one or more destinations, such as clients 110. Applicationserver 345 may be based on open standards/specifications and/orproprietary standards/specifications. TCE servlet 350 may include logicthat operates with application server 345 to provide TCE functionalityto a destination. For example, TCE servlet 350 may receive a requestfrom client 110 and may generate a response, where application server345 makes the response available to client 110 via network 120.

Other implementations of host computers, such as host computer 340B to340N, may include logic that differs from the logic included in hostcomputer 340A. For example, host computer 340B may include TCE 290 andone or more virtual operating systems (OS) 365. Virtual OS 365 mayinclude partitions within a device, such as a server, on which softwareis executed. For example, a server may include three partitions, such asis shown in host computer 340(N) where each partition includes a copy ofvirtual OS 365 running a copy of TCE 290. Virtualization allows a singledevice to run multiple copies of software as if each copy of softwarewere operating by itself on the device. Virtualization is used to allowa device, such as a server, to support multiple users simultaneouslywithout exposing one user's information (e.g., proprietary data) toinformation associated with another user.

Exemplary embodiments can launch or terminate copies of virtual OS 365dynamically, such as based on user demands. In addition, exemplaryembodiments can launch or terminate software applications operatingwithin one or more copies of virtual OS 365 as needed to providescalable processing for substantially any number of users (e.g., clients110).

Exemplary Messaging Exchange

FIG. 4 illustrates exemplary messaging that can be used with browser 220to support network-based technical computing. Messages illustrated inFIG. 4 are illustrative and exemplary embodiments can include moremessages, fewer messages, messages that differ from those illustrated inFIG. 4, and/or messages arranged in orderings that differ from theorderings of FIG. 4.

A user of client 110 may enter a universal resource locator (URL) intobrowser 220, where the URL is associated with a destination thatprovides remote processing resources. For example, the user may enterURL 402 into browser 220, and client 110 may send URL 402 to server 130via network 120. Server 130 may return login information 404 to client110, such as a login screen displayed in browser 220.

The user may enter a user identifier (e.g., a user name) and/or apassword and client 110 may send username and password 406 to server130. Server 130 may forward username and password 406 to database 335,where database 335 performs a lookup operation to determine whether theusername and password are valid. Database 335 may send a session list408 to server 130 when the username and password are valid. Database 335may further maintain information about sessions in which the user and/orclient 110 are engaged. Server 130 may provide information from sessionlist 408 to client 110 via session list page 410. Session list page 410may include a listing of sessions from which the user can choose.

The user may select one or more sessions from session list page 410.Client 110 may send session name 412 for a selected session to TCEservlet 240. TCE servlet 240 may process session name 412 and may returnTCE page 414 to client 110, where TCE page 414 allows the user to enterinformation, such as a command that is compatible with TCE 290.

The user may enter an instruction, such as command 416, into browser 220and client 110 may send command 416 to TCE servlet 240. TCE servlet 240may process command 416 and may forward information in command 416 toTCE 290. TCE 290 may process information in command 416 and may generatean output, such as a result produced by executing an equation containedin command 416. TCE 290 may send TCE output 418 to TCE servlet 240, andTCE servlet 240 may forward TCE output 418 to client 110. The user mayview information in TCE output 418, such as the result, in browser 220.

Exemplary System

FIG. 5 illustrates an exemplary system 500 that can include one or moredata centers. System 500 may include network 120, server 130, LAN 260,data center 510-1 to 510-5 (collectively data centers 510), accounting520 and cluster 530. Data centers 510 may include a number of hardwareor software based processing devices that can be used to perform remoteprocessing. For example, data centers 510 may include a number of UEs270 and management logic to administer UEs within a data center. Forexample data center 510-1 may include its own accounting logic thatcollects charges associated with processing resources within the datacenter. Data center accounting logic may forward its accountinginformation to another device, such as server 130 or accounting 520.Data centers 510 may operate alone (e.g., data center 510-1 and 510-2)or data centers may operate as a group (e.g., cluster 530).

Assume, for sake of example, that a university may include a number ofcomputing centers that each include a number of processing devices,where each processing device is considered a UE. The university mayfurther include management logic that allows the computing centers tocollectively operate as a data center that can be accessed by a userwishing to perform remote processing. A data center may be capable ofprocessing problems that are more complex than problems that can besolved by a UE or a group of UEs (e.g., cluster 330).

Accounting 520 may include logic that performs accounting operations onbehalf of server 130. Accounting 520 may include a database that storesuser information, expense information related to users, credits thatusers may obtain (e.g., when a user makes its processing devicesavailable to other users wishing to perform remote processing), reportgenerating logic (e.g., report generating components, report templates,etc.), audit logic, etc. In one embodiment, accounting 520 may maintainan electronic wallet for a user, where the user can deposit credits intothe wallet and where debits incurred by the user are removed from thewallet. Electronic wallets may provide users with a convenient techniquefor managing costs associated with remote processing activities.

FIG. 6 illustrates an exemplary system 600 that can include two serviceproviders. Exemplary embodiments may include two or more serviceproviders 140 and 640 that can cooperatively operate to provide scalableremote processing resources to a number of customers. For example,service provider 140 may operate cluster 330 and cluster 530 usingserver 130 to provide remote processing resources to users. Anotherservice provider, e.g., service provider 640, may maintain server 630,data center 510-1 and UE 270 to provide remote processing resources tousers.

In one embodiment, service provider 640 may make its processingresources available to service provider 140 periodically, continuously,etc., to allow service provider 140 to service additional users and/orusers with complex processing tasks. Alternatively, service provider 140can provide processing resources to service provider 640 to allowservice provider 640 to better serve its users. Exemplary embodimentscan operate with any number of service providers 140, 640, etc., datacenters 510, UEs 270, clusters 330, 530, etc., without departing fromthe spirit of the invention.

Exemplary Functional Diagram

FIG. 7 illustrates an exemplary functional diagram 700 that includeslogic that can be used to implement server 130 or 630. Functionaldiagram 700 can include processing logic 710, interface logic 720,scheduling logic 730, storage logic 740, accounting logic 750, andsecurity logic 760. Logic in FIG. 7 can reside on a single device, suchas server 130, or the components of FIG. 7 can be distributed acrossmultiple devices. Moreover, the components of FIG. 7 can be implementedin hardware based logic, software based logic, a combination of hardwareand software based logic (e.g., hybrid logic, wetware, etc.). Theimplementation of FIG. 7 is exemplary, and server 130, 630 and/or otherdevices may include more or fewer functional components withoutdeparting from the spirit of the invention.

Processing logic 710 may include logic to process instructions or datarelated to activities. For example, processing logic 710 may instructother logic to perform operations, may parse a user problem into anumber of portions that can be sent to different UEs 270, combineresults received from different UEs 270 into a single result, performarithmetic operations, etc.

Interface logic 220 may send information to or may receive informationfrom another device, component, object (e.g., a software object), etc.In one implementation, interface logic 220 may include a code-basedinterface (e.g., an application program interface (API)), and in anotherimplementation, may include a hardware interface, such as a networkinterface card (NIC).

Scheduling logic 730 may coordinate activities of devices, components,objects, etc., on server 130, 630. For example, scheduling logic 730 maymaintain a list of available resources that can be used for distributedand/or parallel processing (e.g., UEs 270). Scheduling logic 730 maysend information to a determined number of available resources so thatthe resources can perform parallel processing activities using theinformation. For example, scheduling logic 730 may determine that fourUEs 270 are required to perform a simulation on behalf of client 110.Scheduling logic 730 may determine how to schedule portions of thesimulation among the four UEs 270. Scheduling logic 730 may send thesimulation portions to the four UEs 270 via interface logic 720.

Storage logic 740 may store information related to server 130, 630. Inan embodiment, storage logic 740 may store instructions, equations,functions, data, communication protocols, availability information fordevices (e.g., UEs 270), etc.

Accounting logic 750 may perform operations that monitor clientactivities and/or activities of other devices associated with server130/630. For example, accounting logic 750 may measure the amount oftime, processor cycles, memory, types and number of applications ormodules, etc., used by client 110 when client 110 is performing remoteprocessing activities via server 130,630. Accounting logic 750 may alsocompute charges and/or credits for client 110. Accounting logic 750 mayoperate with other devices, such as electronic banking devices externalto server 130,630, when performing accounting operations on behalf ofserver 130,630.

Security logic 760 may perform operations that identify and/or verifythe identity of a user related to client 110 and/or the identities ofdevices that perform remote processing activities on behalf of the user.For example, security logic 760 may verify user identifiers and/orpasswords, client network addresses, may establish communication tunnelson behalf of a client, etc.

Exemplary Data Structure

FIG. 8 illustrates an exemplary data structure 800 that can storeinformation used by server 130. Data structure 800 may be implemented ona computer-readable medium that can be used to store information in amachine-readable format. Information stored in data structure 800 may beprocessed, executed, etc., via processing logic 710. Exemplaryembodiments of server 130 may use substantially any number and/or typeof data structures 800 to store information associated with remoteprocessing. Instances of data structure 800 may be populated via anoperator or a device, such as a device in system 100, 200, etc. In oneimplementation, data structure 800 may include information arranged in arow and column format to facilitate interpretation by an operator ofserver 130, by devices associated with server 130, etc. Otherimplementations of data structure 800 may be configured in other ways.

Data structure 800 may include identifier 810, entry 820, 830, 840, and850 (collectively entries 820). Identifier 810 may include informationthat uniquely identifies an activity performed by server 130, such aspublishing, casting, serving, etc. Entries 820 may include informationrelated to an entry identified using identifier 810. For example, server130 may perform “publishing” (in entry 810) activities using network120. Publishing may include activities that make information availableto a destination. For example, server-based publishing (in entry 820)may make content, such as remote processing content, available to adestination (e.g., client 110) using a server (e.g., server 130, 630,etc.). In a server-based publishing embodiment, a client may accesscontent associated with the server when the client wants to performremote processing activities.

User-based publishing (in entry 830) may allow client 110 to makecontent available to other devices. For example, a user of client 110may write a simulation application that can be used by other clients onsystem 300. Client 110 may make the simulation application available toother clients directly or via a proxy (e.g., client 110 may post theapplication on a web page maintained by a server).

Blog publishing (in entry 840) may allow information related to remoteprocessing to be made available to destination devices via a web log.

Service-based publishing (in entry 850) may make information aboutremote processing available to destinations as part of a service, suchas a subscription-based service.

“Casting” (in identifier 810) may refer to distributing content todestinations using techniques, such as really simple syndication (RSS)feeds (entry 820) and/or other techniques. “Service,” in identifier 810,may refer to services that can be offered using server 130, where theservices can be related to remote processing. For example, server 130may host one or more contests (in entry 820) that are related to remoteprocessing. Examples of contests are, but are not limited to, codingcompetitions where participants attempt to write the most compact,fastest, most accurate, etc., code for a given problem; first to solvecompetitions where the first user to successfully solve a problem wins;etc.

Another type of service is a collaborative service (in entry 840) thatallows users to share and/or collaboratively develop code amongst eachother. For example, a first user may write an application to solve acertain problem and a second user may improve the application. A thirduser may use the improved application to solve the problem and mayprovide feedback to the first and/or second user about the performanceof the improved application.

Implementations of data structure 800 and/or other machine-readablestructures compatible with client 110, server 130, and/or other devicesin FIGS. 1, 2, 3A-C, 5, 6 and 7 can be used locally on a device (e.g.,stored, read, copied, transferred from one component to anothercomponent in that device) or may be sent from one device to anotherdevice over a communication medium (e.g., a wired link, a wireless link,a network, a bus, etc.). Therefore, embodiments of data structuresdiscussed herein are not limited to any particular implementation,format, language, device, configuration, etc. For example, some or allof data structure 800 can be used as code-based interfaces (e.g., APIs)or embedded in hardware to facilitate the exchange of information inexemplary embodiments.

FIGS. 9A-9C illustrate exemplary user interfaces that can be displayedon client 110. In FIG. 9A, interface 900, as well as other interfacesdescribed herein, may be a graphical user interface (GUI) displayed to auser via browser 220 and/or a non-graphical interface, such as a textinterface. Interface 900 and/or other user interfaces described hereinmay further provide information to users via customized interfaces(e.g., proprietary interfaces) and/or interfaces that are generallyknown to and available those of skill in the art (e.g., browser-basedinterfaces).

User interfaces described herein, may receive user inputs via inputdevices, such as but not limited to, keyboards, pointing devices (e.g.,a mouse, stylus, trackball, touchpad, joystick, other types of motiontracking devices, etc.), biometric input devices, touch sensitivedisplays, microphones, etc. User interfaces described herein may be userconfigurable (e.g., a user may change the size of the user interface,information displayed in a user interface, color schemes used by theuser interface, positions of text, images, icons, windows, etc., in theuser interface, etc.) and/or may not be user configurable.

Interface 900 may be displayed to a user via display 210 and may includemenu 905, selection icons 907, display area 909, information window 910,login information 915, session information 920 and cursor 925. Menu 905may include information associated with menus that are accessed by theuser. For example, in one embodiment, menu 905 may identify items, suchas File, Edit, View, etc., that can be selected by a user (e.g., viacursor 925) to open one or more drop down menus. Drop down menus mayprovide the user with substantially any number of items that can beselected by the user to invoke various types of functionality on theuser's behalf. For example, selecting File may open a drop down menuthat includes Open, Close, Save, Save As, Print, Print Preview, etc.Interface 900 may further include icons that let the user performactions, such as moving to a previous display, returning to a homedisplay (or page), printing the contents of a portion of interface 900,etc.

Icons 907 may include mechanisms that perform predetermined functions onbehalf of the user based on a user input. For example, an icon mayinclude an arrow that points in a first direction and allows the user toscroll back to a previous display when the arrow is selected by theuser. In an embodiment, icons 907 may be associated with a piece ofexecutable code (e.g., a widget) that performs an operation on behalf ofa user when icon 907 is selected. Display area 909 may include a portionof display 210 that is used to display information to a user.

Information window 910 may include a portion of a display region that isused to display information to a user, such as information about remoteprocessing performed by the user. Information window 910 may displaytext or graphics to the user. For example, information window 910 maydisplay login information, such as user identification (ID) and password915, session information 920, etc., to a user of client 110. Inaddition, information window 910 may display information about UEs 270,a status of a parallel remote processing task, source code, debugginginformation that allows the user to diagnose code, a dashboard toprovide the user information about a remote processing session, etc.

Cursor 925 may include a mechanism that can be positioned by a user ordevice to identify and/or select information in interface 900. Cursor925 may be positioned within interface 900 via a pointing device, aspoken command, a keyboard input, etc.

FIG. 9B illustrates an exemplary user interface 901 that can include atext window 930 and a graphics window 935. Text window 930 may displaytext information (e.g., debugging information, source code, help guideinformation, operating instructions, etc.) to a user. Graphics window935 may display images, data, diagrams, etc., to a user. In otherembodiments, text and graphics can be displayed to a user via a singlewindow.

FIG. 9C illustrates an exemplary user interface 902 that displays datato a user. Interface 902 may include plot 940 within graphics window935. For example, a user may have performed an optimization onparameters associated with an automobile engine (e.g., optimizing engineperformance over a determined range of engine speeds), where theoptimization was performed using remote processing resources (e.g.,virtualized TCEs) on a network. Results of the optimization may be sentto client 110 and displayed to the user via browser 220 using plot 940.

Graphics window 935 may interact with the user, such as by allowing theuser to select portions of plot 940. For example, the user may movecursor 925 over plot 940 within graphics window 935. Cursor 925 mayoperate with logic (e.g., executable code) that displays informationabout the position of cursor 925 in text window 930. For example, textwindow 930 may display coordinate information for cursor 925 to theuser.

Exemplary Client Processing

FIG. 10 illustrates exemplary processing that may be performed by aclient. A user may access server 130 via client 110 (act 1005). Forexample, the user may enter a URL for server 130. The URL may be sent toserver 130 as message 402 and server 130 may send login 404 to client110 when message 402 is processed. The user may enter a useridentification and/or password and may send them to server 130. Server130 may determine whether the user identification and/or password arevalid. Client 110 may receive an authorization when server 130determines that the user identification and/or password are valid (act1010).

An authorized user/client may select local or remote execution (act1015). For example, a user may select local execution when the userwants to execute a portion of remote processing code locally on client110. In contrast, the user may select remote execution when the userdoes not want to execute remote processing code on client 110. Incertain applications, a user may not wish to download code for localexecution because downloading code may delay execution of remoteprocessing activities until the download is complete. A user may furthernot wish to download code for local execution when the user is operatinga client with limited processing capabilities. For example, a thinclient may not have adequate processing power to execute remoteprocessing code locally.

Client 110 may determine whether local or remote execution is desiredbased on the user selection in act 1015 (act 1020). When remoteexecution is selected by the user, client 110 may send a command toserver 130 for remote execution (act 1025). For example, client 110 maysend a simulation problem to server 130, where the simulation is to berun using remote processing resources connected to server 130. Server130 may parse the simulation into pieces and may send the pieces to twoor more UEs 270 for processing. Server 130 may receive results from UEs270 and may assemble the results into a final result. Client 110 mayreceive the final result from server 130 via network 120 (act 1030).

When client 110 selects local execution at act 1020, client 110 maydownload code from server 130 via network 120 (act 1035). For example,server 130 may send code to client 110 that parses a problem intopieces, determines what UEs 270 are available, sends the problem piecesto identified UEs 270, and assembles UE 270 results into a final result.The user may enter and run a remote processing command locally at client110 (act 1040). Client 110 may interact with two or more UEs 270 toproduce a final result for the user. Client 110 may receive two or moreresults from UEs 270 and may assemble the results into a final result(act 1045). Client 110 may display the final result to the user viadisplay 210.

Exemplary Server Processing

FIG. 11 illustrates exemplary processing that may be performed by server130. Server 130 may operate a web service 250 that exposes a TCE to oneor more clients 110. Web service 250 may process logins, may receiveuser commands, may coordinate remote processing activities on behalf ofclients 110, and may send results to clients 110.

Server 130 may receive a login request from client 110 using web service250 (act 1105). For example, server 130 may receive message 406. Server130 may process the login request and may authorize client 110 (act1110). For example, server 130 may use security logic 760 and/or userinformation from database 335 to authorize client 110.

Server 130 may select local or remote execution based on informationreceived from client 110 or based on information in database 335 (act1120). For example, server 130 may receive a request for local or remoteexecution from client 110. Alternatively, server 130 may maintaininformation in database 335 as to whether client 110 should run in alocal or remote mode. For example, database 335 may include informationthat indicates client 110 has only rudimentary processing capabilities;and, therefore, client 110 should always run via remote execution (i.e.,client 110 should not run remote processing code locally).

Server 130 may determine that client 110 should operate via remoteexecution (act 1130), and server 130 may receive a command from client110, where the command is for remote processing (act 1145). Server 130may process the command (e.g., may process command 416) and may send theprocessed command to one or more UEs 270. For example, server 130 maydetermine that the command should be sent to two UEs operatingindividually and to one cluster that includes three UEs. Server 130 maysend the command and any necessary data (e.g., data that will beoperated on by the command) to the two individual UEs and to thecluster) (act 1150).

Server 130 may receive results from devices performing remote processingon behalf of client 110 (act 1155). For example, server 130 may receivea first result from a first one of the two individual UEs, a secondresult from the second UE and a third result from the cluster. Server130 may assemble the results into a final result, where the final resultincludes information from the first result, the second result and thethird result. Server 130 may send the final result to client 110 vianetwork 120 (act 1160). Client 110 may display the final result to theuser via, for example, browser 220.

When server 130 determines that local execution should be used in act1130, server 130 may send code to client 110 or to a user of client 110(act 1140)

FIG. 12 illustrates exemplary processing that may be performed by aserver. Server 130 may make determinations with respect to processingresources that can be used on behalf of client 110 to perform remoteprocessing. For example, server 130 may receive a command from client110, where the command includes an instruction that can be processed byremote (e.g., distributed) devices (act 1205). Server 130 may processthe command to determine how the command should be allocated amongremote processing resources (e.g., UEs 270). For example, server 130 mayperform a database lookup using database 335 to identify resources thatcan be used for remote processing on behalf of client 110.

Server 130 may identify appropriate remote processing resources (act1210). For example, server 130 may determine that the command should beoperated on by cluster 530 and data center 510-1. In one embodiment,server 130 may make this determination based on the availability ofcluster 530 and data center 510-1. In another embodiment, server 130 maymake the determination based on a priority associated with the commandand/or client 110, based on a fee that client 110 is willing to pay forremote processing, etc.

Server 130 may determine whether parallel processing should be performedon the command, and/or data operated on using the command (act 1220).When server 130 determines that parallel processing should be performed,server 130 may identify resources that can perform the parallelprocessing.

Server 130 may parse the command and/or data (act 1225). For example,server 130 may determine that cluster 530 and data center 510-1 are themost desirable resources to perform parallel processing on the command;however, when server 130 attempts to send the request to data center510-1, data center 510-1 may inform server 130 that it is busy andcannot perform processing on behalf of client 110. Server 130 maydynamically adjust configuration of parallel processing resources basedon the busy status of data center 510-1 and may send a portion of thecommand to data center 510-2.

Server 130 may send parsed information, such as the command, to devicesthat perform parallel processing on behalf of client 110 (act 1230). Theremote devices may operate on their portions of the command and mayproduce results that are sent to server 130. Server 130 may assemble theresults into a final result (act 1235) and may send the final result toclient 110.

In act 1220, server 130 may determine that parallel processing shouldnot be performed. Server 130 may send a command received from client 110and/or data received from client 110 to a single processing device (act1240), where the single device performs processing for client 110.Server 130 may receive a result from the processing device (act 1245)and may send the result to client 110.

Exemplary embodiments may be deployed in a number of arrangements toperform types of remote technical computing tasks. For example,embodiments may participate in remote computing using variouscommunication link configurations, using a quick command service, usingscheduled sessions, using a number similar software applications, usingresources that compute results within a determined time interval, usinglogic that monitors computing applications, and using published code.Examples of these embodiments will be further described below.

Exemplary Unit of Execution Arrangements

Client 110 may operate in a number of configurations to perform remoteprocessing using two or more units of execution. FIGS. 13A-E illustratehigh level schematics of selected exemplary configurations that can beused to provide client 110 with a number of remote processing servicesvia UEs 270.

FIG. 13A illustrates a client 110 that maintains a number of connections(e.g., links) to a network when performing remote processing activities.In the embodiment of FIG. 13A, network 120 may include hardware and/orsoftware devices that receive requests from client 110 via links 1310.For example, client 110 may wish to use four remote processing servicesand may initiate four links with network 120. By way of example, client110 may wish to use a collaborative coding service, a remote testingservice, a remote processing service, and a remote coding competitionservice (e.g., a service that allows client 110 to participate incontests where participants generate code to see which programmer writesthe most efficient, shortest, or simplest piece of code to solve aparticular problem). Network 120 may send the first request for thecollaborative coding service to a first UE (e.g., UE 270(1)), the secondrequest for the remote testing service to a second UE (e.g., UE 270(2)),the third request for the remote processing service to a third UE (e.g.,UE 270(3)), and the fourth request for the collaborative coding serviceto a fourth UE (e.g., UE 270(4)). The respective services may returnresults to client 110 via network 120 and the four links 1310.

In the embodiment of FIG. 13A, client 110 may dynamically set up and/orteardown links 1310. For example, client 110 may set up or teardownlinks based on processing needs, computation costs, etc. By way ofexample, assume that UE 270(1) finishes processing before another UE,e.g., UEs 270(2), (3) and (4). Further assume that client 110 tears downlink 1310 when client 110 receives results from UE 270(1) while leavinglinks to the other UEs in place. Alternatively, client 110 may teardowna link to another UE, e.g., UE 270(2) and may shift traffic from thatlink to UE 270(1) via link 1310.

FIG. 13B illustrates an exemplary embodiment that allows client 110 tomaintain a number of links with a network device (e.g., a farm manager)when using one or more remote services. In FIG. 13B, client 110 mayinitiate four links 1310 with a network device that can communicate withone or more destination devices, directly or indirectly. For example,client 110 may initiate links 1310 with farm manager 320, where farmmanager 320 maintains direct connections to UEs 270(1)-270(4). Client110 may request the collaborative coding service, a remote testingservice, a remote processing service, and a remote coding competitionservice discussed in FIG. 13A via farm manager 320. Farm manager 320 mayprovide results to client 110 via links 1310.

FIG. 13C illustrates an exemplary embodiment that allows client 110 torequest one or more services using a single link to a farm manager 320.In FIG. 13C, client 110 may communicate with farm manager 320 over asingle link 1320, such as an Internet connection over an optical fiber,coaxial cable, Wi-Fi link, cellular telephone link, satellite link, etc.For example, client 110 may request the collaborative coding service,the remote testing service, the remote processing service, and theremote coding competition service discussed in FIGS. 13A and B from farmmanager 320 over link 1320. Farm manager 320 may operate UEs270(1)-270(4) to provide the services to client 110. Farm manager 320may send results from the services to client 110 over link 1320.

FIG. 13D illustrates an exemplary embodiment that allows client 110 torequest services through farm manager 320 via a single link. In FIG.13C, farm manager 320 may operate UEs that can perform UE to UEcommunications directly or indirectly. For example, client 110 mayrequest a collaborative coding service, a remote testing service, aremote processing service, and a remote coding competition service overa single link 1320. Farm manager 320 may use UEs 270(1)-270(4) toprovide the services to client 110. In the embodiment of FIG. 13D, UEs270(1)-270(4) can communicate with each other, which may allow one UE toassist another UE with providing a portion of a requested service. Forexample, UE 270(1) may request assistance from UE 270(2) when code iscompiled on behalf of client 110. In one embodiment, UEs 270(1)-270(4)may communicate with each other without requiring instructions fromclient 110 and/or farm manager 320. In another embodiment, client 110and/or farm manager 320 may provide instructions to UEs 270(1)-270(4)that allow the UEs to communicate amongst each other. The embodiment ofFIG. 13D may further allow UEs to share resources, such as memory,workspaces, etc.

FIG. 13E illustrates an exemplary embodiment that allows client 110 tocommunicate with a firewall 1340 when performing remote processingactivities. In FIG. 13E, client 110 may send requests for the servicesof FIG. 13A to firewall 1340. Firewall 1340 may process requestsreceived from client 110 to determine how to allocate requests to UEs.Firewall 1340 may send a request for one service, e.g., thecollaborative coding service to UE 270(5) directly (as shown in FIG. 13Evia link 1350) or indirectly. Firewall 1340 may determine that requestsfor the remote testing service, the remote processing service, and theremote coding competition service should be sent to different UEs. InFIG. 13E, firewall 1340 may send the requests for the other services tocluster 330 via link 1360. Cluster 330 may determine that its UEs arenot available to process the requests received from firewall 1340.

Cluster 330 may send the requests for the remote testing service, theremote processing service, and the remote coding competition service toUEs outside cluster 330. For example, cluster 330 may send the remotetesting service request to UE 270(2), the remote processing servicerequest to UE 270(3), and the collaborative coding service request to UE270(4). In the embodiment of FIG. 13E, UE 270(3) and UE 270(4) may beable to communicate with each other via path 1370 (e.g., a bus oranother type of interconnect) to allow sharing of processing resourcesbetween the two UEs. In the embodiment of FIG. 13E, firewall 1340 maysend requests to services via fixed links (e.g., link 1320) and/orwireless links, such as wireless link 1380.

Other exemplary embodiments may take other forms when providing remoteservices to one or more clients without departing from the spirit of theinvention. For example, an exemplary embodiment may provide a windowthat allows a user to quickly evaluate a technical computing commandwithout requiring that the user be running a technical computingapplication locally on the user's device (e.g., client 110).

Exemplary Quick Command Embodiment

FIG. 14 illustrates an exemplary embodiment that can implement a quickcommand window. FIG. 14 can include client 110, network 120, browser220, web client 230 and server 130 that can include TCE servlet 240,MATLAB® service 250 and quick command service 1410. Client 110, network120, server 130, browser 220, web client 230, TCE servlet 240, andMATLAB service 250 may be configured and may operate as previouslydescribed.

Quick command service 1410 may include software that provides a browserbased quick command window to client 110. In one embodiment, quickcommand service 1410 may be configured to quickly execute commands onbehalf of a user. For example, a browser based quick command service mayexecute single commands much faster than the single commands can beexecuted locally on client 110 when client 110 is running a localversion of a technical computing application (e.g., a MATLAB softwareapplication).

Assume, for sake of example that a user wishes to execute a MATLABcommand on his local machine. The user may launch a MATLAB applicationon his computer and may have to wait for thirty seconds while theapplication loads on the local machine. Using the quick command service,the user may type a command into a quick command window while working inan application while the MATLAB application is not open, loaded, orresident on the local machine. The user may type the command into thequick command window and a result for the command may be displayed tothe user without requiring that the user wait for the MATLAB applicationto load. In fact, the result may be displayed to the user almostinstantaneously once the user enters the command. In one embodiment, thequick command service may use a MATLAB application is that alwaysrunning on a remote device with respect to the local machine, such as aserver connected to the local machine via a network.

Embodiments of quick command service 1410 may be implemented as widgetsto allow a user to interact with a window, such as a quick commandwindow, within browser 220. In one embodiment, the window may be an HTMLinput window that is interfaced to an output region on browser 220(e.g., an output window).

FIG. 15A illustrates an embodiment of quick command service 1410 that isprovided via a widget. The embodiment of FIG. 15A may include userinterface 1501, quick command widget 1520 and data display window 1530.User interface 1501 may include a browser window and may display textand/or graphics to a user of client 110. Quick command widget 1520 mayinclude a window that a user selects to interact with quick commandservice 1410. For example, a user may type a command into quick commandwidget 1520 in one embodiment. Or, in another embodiment, the user maydouble click on quick command widget 1520 to open a larger dialoguewindow. Data display window 1530 may include a display region thatallows a user to view results of processed commands (e.g., commandsentered into quick command widget 1520).

FIG. 15B illustrates an embodiment of quick command service 1410 thatuses an enlarged quick command widget for receiving user inputs. FIG.15A may include user interface 1501, quick command widget 1520, textoutput region 1532 and graphic output region 1534. A user may enter acommand into quick command widget 1520, such as x=1:10. The user mayfurther wish to plot x=1:10 and may enter a plot command, such asplot(x) into quick command widget 1520. Information entered into quickcommand widget 1520 may be sent from web client 230 to server 130 overnetwork 120. On server 130, the user inputs may be processed by quickcommand service 1410 and/or MATLAB service 250 to generate a result.

A result may include text, graphics, audio, etc. For example, quickcommand service 1410 may process x=1:10 and plot(x) and may producetextual results and graphical results. Quick command service 1410 maysend the textual and graphical results to client 110. Web client 230 mayprocess the received results and may send them to browser 220. Browser220 may display the textual portion of the results in a text outputregion 1532 and the graphical portion of the results in graphic outputregion 1534. In one embodiment, text output region 1532 and/or graphicoutput region 1534 may include windows for displaying results to theuser.

Quick command service 1410 may let users rapidly prototype and/orunderstand how certain commands, functions, etc., perform. In addition,quick command service 1410 may let the user quickly obtain helpregarding a command, function, etc. Assume, for sake of example, that auser is interacting with an application (e.g., a spreadsheetapplication) that is implemented in a statically typed programminglanguage, such as the C programming language, via user interface 1501.The user may wish to evaluate an expression using a dynamically typedprogramming language to quickly determine whether the expression isacceptable for inclusion into the spreadsheet application. The user maywish to prototype the expression in the dynamically typed languagebecause processing the expression in the spreadsheet application maytake too long.

In this example, the user may wish to interact with a technicalcomputing application to evaluate the expression. The user may be ableto evaluate the expression in the technical computing application viaquick command service 1410. The user may select quick command widget1520 while the spread sheet application is open in browser 220.Selecting quick command widget 1520 may associate a remote application(here the technical computing application) with quick command widget1520 so that the expression can be evaluated.

The user may enter the expression in quick command window 1520 and theremote application may receive the expression. The remote applicationmay use one or more remote processing resources (e.g., UEs 270) toevaluate the expression using the technical computing application toproduce a result. The remote application may send the result to client110 where the result may be displayed in user interface 1501.

The user may view the result and may decide that he/she wants to performadditional computations using the remote application. For example, theuser may wish to write scripts that can be executed on the remoteapplication to produce other results. The user may launch the remoteapplication by, for example, selecting a launch application button onuser interface 1501. Selecting the launch application button may send arequest from client 110 to a device hosting quick command service 1410and the device may provide the full capabilities of the remoteapplication to client 110 via user interface 1501. For example, thespreadsheet application may be closed and a user dialog screen for aremote technical computing application may be provided to the user. Theuser may be able to access all of the capabilities of the remotetechnical computing application via the dialog screen. For example, theuser may be able to execute a number of MATLAB commands using the remotetechnical computing application to produce a number of results.

Other embodiments of quick command service 1410 can be implemented in avariety of ways. For example, another embodiment of quick commandservice 1410 may include a special key on a user's keyboard. Depressingthe special key may open a quick command widget that allows a user toquickly enter and evaluate a command. Depressing the special button asecond time may close the quick command widget and may remove displayedquick command results from the user's display device.

Other exemplary embodiments may perform other types of remote tasks onbehalf of a client. For example, an embodiment may run scheduledsessions using a technical computing application.

Exemplary Scheduled Session Embodiment

FIG. 16A illustrates a user interface that can be used to scheduleprocessing sessions with a remote technical computing service. Forexample, a finance administrator may wish to run the contents of a filethat causes one or more reports to be run. In one embodiment, thefinance administrator may want to run the contents of an M-file thatruns a report using a remote MATLAB service (e.g., MATLAB service 250).For example, server 130 in FIG. 14A may include a module that allowsscheduled sessions to be run using MATLAB service 250.

Referring to FIG. 16A, user interface 1600 may include code name field1610, runtime field 1620, report identifier field 1630, add/removebuttons 1635, and check boxes 1637. Interface 1600 may be displayed onclient 110 using, for example, browser 220. A user of client 110 may useinterface 1600 to set up a scheduled session.

Code name field 1610 may include user entries that identify filecontents to be run. For example, code name field 1610 may include thenames of jobs, files, folders, etc., that include content that will beexecuted via the remote technical computing service.

Runtime field 1620 may include entries that identify when correspondingfile contents identified under code name field 1610 should be run. Forexample, runtime field 1620 may include start times, start dates, etc.,that identify when a respective job, file, folder, etc., should beexecuted via a remote technical computing service.

Report identifier field 1630 may include entries (e.g., file names) thatidentify data structures for holding results produced when entries undercode name field 1610 are run.

Add/remove buttons 1635 may allow a user to add or remove entries frominterface 1600. For example, selecting the add button may open a windowin interface 1600 or may move a cursor to a position within interface1600 that allows the user to enter a filename in code name field 1610, aruntime value in runtime field 1620, or a filename in report indenterfield 1630. In contrast, selecting the remove button may let a userdelete information from interface 1600. Check box 1637 may let a userselect which reports to run. For example, a user may double click on thecheck box 1637 proximate to FINANCE.m and a check mark may appear incheck box 1637. The check mark may indicate that an output file namedAUG-18-07.TXT will be generated when FINANCE.m is run at 0600 hours.

Exemplary embodiments may generate a new user interface when a report isrun for an entry in FIG. 16A. For example, a results window may begenerated that contains information about each file that was processed.Assume, for sake of example, that a user specifies a number of jobs andstart times for the jobs in interface 1600. Further assume that thedesignated start times arrive. A scheduler may operate as part of theremote technical computing service and may identify available remoteprocessing resources.

For example, the scheduler may receive the job information and starttimes from interface 1600. The scheduler may identify remote processingresources (e.g., UEs 270) that are available to perform remoteprocessing on the jobs. The scheduler may send the jobs to availableremote processing resources at the identified start times and mayreceive results from the remote processing resources when processing iscomplete. In one embodiment, the scheduler may divide a job into partsand may send a first part to one remote processing resource and may sendanother part to another remote processing resource. The scheduler mayreceive a first result for the first part and a second result for thesecond part when processing activities are complete. The scheduler mayassemble the first result and the second result into a complete result,or final result, that can be displayed to the user via interface 1600 orstored in a storage device.

In an embodiment, the scheduler may dynamically schedule jobs among anumber of remote processing resources. In dynamic scheduling, thescheduler may allocate or de-allocate jobs among remote processingresources while processing is performed. Dynamic scheduling may allowreal-time load balancing of processing for a particular job or for aparticular arrangement (e.g., cluster or pool) or remote processingresources. Dynamic scheduling may further allow remote processingresources to be identified and/or selected based on criteria, such asprocessing costs, processing speeds, memory sizes, locations (e.g.,geographic locations of remote processing resources), input speeds forremote processing resources, output speeds for remote processingresources, security policies for remote processing resources, etc.

FIG. 16B illustrates a results window for a scheduled session that hasrun. Results window 1602 may include code name field 1610, runtime field1620, successful field 1640 and report identifier field 1630. Successfulfield 1640 may include information that identifies whether a report wasrun successfully. For example, successful field 1640 may includeinformation that indicates that a report ran successfully (e.g., YES inFIG. 16B), that a report only ran partially (e.g., PARTIAL in FIG. 16B),that a report did not run (not shown in FIG. 16B), etc.

Embodiments, such as the ones illustrated in FIGS. 16A and 16B may runreports for substantially any type of information, such as financialinformation, test data, weather data, population data, sports data,education data, etc.

Other embodiments can be used to perform other tasks, such as comparingthe operation of various versions (e.g., releases) of one or moresoftware applications. For example, an engineering manager may berunning two different versions of a technical computing application(e.g., MATLAB software, Simulink software, etc.) within his group. Theengineering manager may wish to determine if both versions of thesoftware produce the same results when run against a particular input,such as some or all of the problems, models, data sets, etc., usedwithin the group.

In another example, the engineering manager may be considering whetherto upgrade legacy versions of technical computing applications to a mostrecent version of the application. Before investing in the new software,the manager may wish to determine if the new version produces the sameresults as the legacy versions of the technical computing application.

Other exemplary embodiments may perform other types of remote tasks onbehalf of a client. For example, an embodiment may allow a manager tocompare operation of multiple versions of a technical computingapplication and/or another type of application simultaneously.

Exemplary Simultaneous Execution Applications

By way of example, server 130 in FIG. 14A may include a module that runsmultiple versions of a technical computing application against eachother using a predetermined input (e.g., problem, model, data set,etc.). Assume client 110 identifies a problem and versions of a softwareapplication (e.g., a technical computing application) that will be runagainst the problem in parallel (e.g., at substantially the same time).In one embodiment, server 130 may dynamically determine availableversions of a technical computing application associated with client 110and/or available from other locations or sources (e.g., a latest versionof the technical computing application available from a manufacturer ordistributor). Server 130 may display information about availableversions of the technical computing applications to client 110 viapop-up windows and/or other techniques using browser 220.

Further assume server 130 executes the selected versions of thetechnical computing application against each other line-by-line. Forexample, server 130 may execute the first application on a first remoteprocessing resource and the second application on a second remoteprocessing resource. Server 130 may stop executing and may provide anerror and/or intermediate result to client 110 when answers between twoor more compared versions begin to diverge. Alternatively, server 130may identify locations in compared versions where results begin todiverge and may continue running the versions until a fatal error isencountered or until final results are produced, even if the finalresults vary between the compared versions.

In one embodiment, server 130 may use synchronization logic to performline-by-line execution between two versions of a technical computingapplication even when the two versions may contain a different number oflines of code with respect to each other, may be written in differentlanguages, may run on different platforms (e.g., different operatingsystems), etc.

FIG. 17A illustrates an exemplary user interface that can be used tocompare the operation of multiple versions of a software application.FIG. 17A includes user interface 1700 that can include input name 1710,output name 1720, revision identifier 1730, information field 1740,platform field 1750, and add/remove buttons 1755.

Input name 1710 may include information that identifies the name of aproblem, data set, model, etc., against which multiple versions of thesoftware application are run. Input name 1710 may include, for example,a filename, a link, an address, etc., that identifies information inputto two or more software applications. Output name 1720 may includeinformation that identifies a result produced by the two or moresoftware applications when run against the filename, link, address,etc., identified in input name 1710. Output name 1720 may include afilename, a link, an address, etc. Information associated with outputname 1720 may include text, graphics, audio, video, etc., depending onthe types of results produced by the two or more software applications.

Revision identifier 1730 may include information that identifiessoftware applications that will be run against a problem, data set,model, etc., identified by input name 1710. Revision identifier 1730 mayinclude a filename, link, address, etc. For example, revision identifiermay include version names or version numbers for respective softwareapplications that will be run against a particular problem. In FIG. 17A,revision identifiers 1730 may include names like release 14 of a MATLABsoftware application, release 2006.b of a MATLAB software application,or release 2007 of a MATLAB software application. Other embodiments mayinclude information identifying other types of programs.

Information identifier 1740 may include types of information thatfurther elaborate on entries in revision identifier 1730. For example,information identifier 1740 may indicate a release date for a softwareapplication, indicate a size of a software application, indicate thelast time a software application was used, etc. Platform identifier 1750may include information that identifies a platform on which a softwareapplication is run. For example, platform identifier 1750 may includeoperating system identifiers, hardware platform identifiers (e.g., typeof microprocessor, memory configuration, etc.), and/or other types ofinformation related to a platform on which a software application isrun.

Add/remove buttons 1755 can include logic that allows a user to enter ordelete information from user interface 1700. User interface 1700 mayfurther include check boxes that can be used to activate or deactivateentries. For example, placing a check mark next to an entry in userinterface 1700 may cause a software application associated with theentry to be run against a problem identifier in input name 1710.

User interface 1700 may allow client 110 to compare the operation of twoor more software applications against each other with respect to asingle problem. For example, a problem for a control system can beidentified via input name 1710 and an output file can be identified viaoutput name 1720. Client 110 may further identify three versions of aMATLAB software application to run against the control system problem,namely release 14, release 2006.b, and release 2007. In addition, someof the software applications may be run on multiple platforms againstthe control system problem (e.g., release 2006.b which can be run onLINUX, UNIX, and Windows XP, and release 2007 which can be run on anImac compatible operating system and UNIX).

Server 130 may run the identified software applications against theproblem in parallel and may generate a result file that includes resultsfrom the respective software applications. For example, in oneembodiment, two versions may be started at the same time so as tooperate in parallel. In another embodiment, a first version may bestarted at a first time and a second version may be started at a secondtime that occurs after the first time. As long as the two versions areoperating at the same time for at least one time increment, the twoversions are considered to be running in parallel.

Embodiments may store and/or display information to a user via a resultsfile on client 110. In one embodiment, result information may bedisplayed on client 110 in an arrangement that lets a user of client 110quickly compare results among the software versions that were run inparallel against the problem. For example, a user may view a firstresult for a first version of a software application and a second resultfor a second version of the software application via browser 220. Theuser may evaluate the performance of the first and second versions withrespect to an input to determine which version performed best.Embodiments may further store results for the compared versions via astorage device.

FIG. 17B illustrates an embodiment of a user interface that may displayresults on client 110. FIG. 17B may include user interface 1702 thatdisplays results for software versions that were run in parallel againsta particular problem, data set, model, etc. For example, user interface1702 may include text output 1760 and graphics output 1765 for release14, text output 1770 and graphics output 1775 for release 2006.b, andtext output 1780 and graphics output 1785 for release 2007. In theembodiment of FIG. 17B, the text output and the graphics output may bedisplayed in respective windows via user interface 1702. Otherembodiments may display results to a user in different ways. Forexample, a user interface may include information about the problem,information about the results, and logic to let a user launch one ormore versions of the software applications that were run against theproblem.

FIG. 17C illustrates an embodiment that may display a problem, one ormore results, and logic that can launch a software application on client110. FIG. 17C can include user interface 1704. User interface 1704 canin turn include problem window 1790 and information about versions ofsoftware applications run against the problem. For example, userinterface 1704 can include text output 1760, graphic output 1765 andlaunch to desktop button 1787 for release 14. Launch to desktop button1787 may include logic that lets a user of client 110 launch arespective software application to a desktop of client 110. For example,a user may determine, based on information displayed in user interface1704, that he/she is happy with the results produced by release 14. Theuser may select launch to desktop button 1787 by, for example, doubleclicking on button 1787. A copy of release 14 may be downloaded toclient 110 and launched in response to the user's selection.Alternatively, release 14 may already be resident on client 110 and maybe retrieved from local storage and launched in response to the user'sselection. In still another embodiment, release 14 may run on a desktopof client 110 via a remote computer, e.g., server 130 in response to theuser's selection.

User interface 1704 may further include an expand/collapse arrow (blacktriangle in FIG. 17C) that can be used to expand and/or collapseinformation related to a software application. For example, userinterface 1704 may provide summary results for each software applicationand a user may select an expand/collapse marker to see additionalinformation about results for a particular software application.

User interface 1704 may further include text output 1770, graphicsoutput 1775, and launch to desktop button 1787 for release 2006.b; andtext output 1780, graphics output 1785, and launch to desktop button1787 for release 2007.

Alternative embodiments that compare execution of two or more versionsof a software application may include threshold logic that is used todetermine when results for the two applications diverge. For example, auser may specify a threshold value that identifies a minimum or maximumacceptable deviation between a first result produced by a first versionof a software application and a second result produced by a secondversion of the software application. Parallel execution of the twoversions may stop when deviation between the first result and the secondresult meets or exceeds the threshold value.

In still other alternative embodiments that compare two or morerevisions of a software application, intermediate results may begenerated. For example, each version of the software application maycontain three code modules where each module produces an intermediateresult when executed. A user may specify a threshold value for eachmodule and/or a threshold value for the entire application. In thisexample, three intermediate results may be generated when the twoversions of the software application are executed against each other inparallel.

Other exemplary embodiments may perform other types of remote tasks onbehalf of a client. For example, an embodiment may perform a number ofcalculations within a predetermined interval for client 110.

Exemplary Interval Bounded Processing

Assume, for sake of example, that a financial analyst has a number offinancial calculations that must be performed before financial marketsopen the next day. The analyst may use an exemplary embodiment toperform the financial calculations within a determined interval. Theanalyst may identify a time by which the calculations must be performedand/or other parameters, such as cost, security protocols, etc. Forexample, the analyst may be able to specify that calculations must becomplete by 7:00 AM the next day and that the calculations should beperformed as inexpensively as possible.

An embodiment may accept inputs on behalf of the analyst and maydistribute computations that use the inputs among a number of remoteprocessing resources that run technical computing applications forperforming processing activities on behalf of a requesting device. Theembodiment, may include logic that estimates the number of resourcesand/or computational power of resources required to perform desiredcalculations within a specified interval (here 7:00 AM the next day). Inaddition, the embodiment may dynamically identify and/or reserve remoteprocessing resources based on calculations to be performed and/or otherparameters (e.g., cost, etc.). The embodiment may parse the calculationsinto portions and may send the portions to reserved resources for remoteprocessing. The reserved resources may send results to the embodimentwhen remote processing is complete, and the received results may beassembled into a format that is useful to the analyst. For example, theembodiment may display results to the analyst in a format that allowsthe analyst to make predications about how financial markets willperform when they open the following day.

FIG. 18 illustrates an embodiment that can be used to performcalculations within a determined interval. FIG. 18 may include userinterface 1800, command window 1810, data files window 1820, optionswindow 1830, and graphics output window 1840. In an embodiment, server130 of FIG. 14 may include a module that performs distributedcalculations within a predetermined interval. The module may provideuser interface 1800 to client 110, may dynamically identify and/orreserve processing resources based on user selections input to userinterface 1800, and may provide results to user interface 1800 whendistributed processing is complete.

Command window 1810 may include a window for receiving user inputs. Forexample, a user may enter commands, functions, scripts, etc., in commandwindow 1810. Information entered in command window 1810 may be used toprocess data, perform simulations, generate graphical displays, etc.Data files window 1820 may include information that is operated on bycommands in command window 1810 to produce results. For example, datafiles window 1820 can include the names of files that include financialdata that is processed to produce one or more results. In otherembodiments, data files window 1820 may include links, addresses, etc.,that identify data used with interface 1800.

Options window 1830 may include information related to remote processingactivities performed on behalf of client 110. For example, a user mayenter criteria associated with the remote processing into options window1830. For example, a user may enter a completion time, names of theprocessing resources that will be used in the remote processing,addresses for the processing resources, costs associated with theprocessing resources, an estimated completion time, storage requirementsfor results generated by the processing, etc.

In an embodiment, a user may modify information in options window 1830.For example, the user may remove an identifier (e.g., name) for aresource that has a high cost. The user may enter information for one ormore other resources having lower costs in place of the removed resourceand may run calculations using the lower cost resources. For example,the user may delete the name of one high cost resource and may replaceit with the names of two lower cost resources. In another embodiment,interface 1800 may include a dial, slider, etc., that allows the user tochange processing resource names, speeds, memory sizes, etc. Forexample, a user may move a graphical dial clockwise and namesprogressively faster processing resources may appear in options window1830. In contrast, when the user moves the graphical dialcounter-clockwise names for lower speed processing resources may appearin options window 1830.

Graphics output window 1840 may include graphical information related toprocessing performed on behalf of client 110. In one embodiment,graphics output window 1840 may include plots, images, etc., of resultsproduced when data files are operated on by commands in command window1810. In another embodiment, graphics output window 1840 may includegraphs of performance data (e.g., percent completion, CPU usage ofremote resources, workspace usage, etc.) related to remote processingactivities performed on behalf of client 110.

In one embodiment, a user may run a technical computing application atclient 110 (e.g., a local copy or a remotely accessed copy). The usermay access remote processing resources that will perform a desiredcalculation prior to a determined time. In one embodiment, remoteprocessing resources may be provided via a virtualized operating systemthat can be served from a number of CPU's (e.g., CPUs associated with anumber or remote processing devices). Use of virtualized resourcesfacilitates dynamically moving a processing task from one resource toanother resource (e.g., a processing task can be moved from a slowerresource to a faster resource during a calculation). In an embodiment,the user may request resources that are operated by the user (i.e., theuser may own the resources) or an organization to which the user belongs(e.g., a corporation that employs the user), or the user may requestresources that are owned by a third party with respect to the user(e.g., the user may rent processing resources from the third party).

In the embodiment of FIG. 18, logic may determine the number and typesof devices required to perform desired processing on behalf of the user.For example, the logic may determine whether processing should beperformed by remote clusters or a number of individual remote devicesand/or whether single core or multicore machines should be used. Thelogic may further determine whether machines with high speed processorsare needed or whether machines with standard speed processor aresatisfactory. The logic may also make other determinations, such aswhether machines with large memory capacities are needed to complete theprocessing before the determined time.

Other exemplary embodiments may perform other types of remote tasks onbehalf of a device. For example, an embodiment may be used to monitoractivities performed by a number of users.

Exemplary Client Device Monitoring

For example, a technical computing application may be hosted as a webservice (e.g., within a corporation). The hosted technical computingapplication may be used by a number of users (e.g., developers) at anygiven time. The hosted technical computing application may include amodule that monitors usage of the application by the developers. Forexample, server 130 in FIG. 14 may include monitoring logic thatdetermines how often each developer runs the hosted application, thetypes of operations performed by the developers (e.g., writing code,compiling code, debugging code, and/or executing code), etc.

FIG. 19 illustrates a hosted embodiment that can monitor applicationusage by a number of developers. FIG. 19 includes system 1900 that caninclude service provider 140, LAN 260, cluster 530, developers 1910-1 toN (collectively developers 1910), manager 1920, and engineering database1930. In one embodiment, system 1900 may be deployed within acorporation, an institution (e.g., a university), a government agency,etc. Developers 1910 may include clients 110 that are used by softwaredevelopers to write code, debug code, execute code, generatedocumentation, etc. For example, developers 1910 may write code formodeling physical systems.

Manager 1920 may include a computing device that interacts withdevelopers 1910. For example, a supervisor of a software engineeringgroup may operate manager 1920 to monitor and/or coordinate activitiesof software developers working at developers 1910. The supervisor mayissues tasks, receive time cards, receive reports, monitor usage, etc.,of developers 1910 using manager 1920. Assume that the supervisor wantsto determine how a software application is being used within anorganization so that decisions can be made with respect to the softwareapplication, individuals working with the software application, etc. Thesupervisor may use manager 1920 to monitor developers' activities withthe software application. For example, the supervisor may determine howoften developer 1910-1 interacts with the software application.

Engineering database 1930 may store and/or process information relatedto developers 1910, manager 1920 and/or software applications used insystem 1900. For example, engineering database 1930 may storeinformation about usage of software applications operated in system1900. Database 1930 may further process the stored information and maygenerate reports for manager 1920.

FIG. 20 illustrates an exemplary user interface 2000 that can displayusage information about the software application used in system 1900.For example, user interface 2000 may be displayed to the supervisor viaa display device on manager 1920. User interface 2000 may includedisplay area 2010, window 2020, installed information 2030, usedinformation 2040, and detail button 2050. Display area 2010 may includea region of, for example, browser 220 that displays information about asoftware application that is used by developers 1910. Display area 2010may display text, graphics, etc., to provide the supervisor withinformation about the software application and/or developers 1910.

Window 2020 may include information that identifies versions of asoftware application (e.g., number of seats installed), usageinformation for the installed versions, etc. For example, window 2020may indicate the number of seats of a technical computing application(e.g., MATLAB software) that are installed in an engineering departmentat a corporation. For example, installed information 2030 may identifythe number of seats installed within the engineering department. Window2020 may further include information related to the installed seats. Forexample, used information 2040 may indicate the number of seats usedwithin determined intervals (e.g., within the last 30 days, 60 days, 90days, etc.) Used information 2040 may further identify seats that havenot been used within a determined interval, e.g., not used within 90days. Information about seat usage may be used by the engineeringmanager to perform, for example, wear based analysis on the softwareapplications (e.g., by identifying “worn applications” which areapplications that are frequently used).

Window 2020 may further include detail button 2050 that can be selectedto display additional information about one or more of used information2040. For example, a supervisor may double click on detail button 2050(“30 day Detail”) to obtain additional information about seats usedwithin the last 30 days.

FIG. 21 illustrates a user interface that can be used to displayadditional information about a software application. For example, userinterface 2100 may be displayed to the supervisor when detail button2050 is selected. User interface 2100 may include used information 2040,display area 2110, window 2120, engineer identifier 2140, time inapplication 2150, time writing code 2160, time running code 2170, andtime debugging code 2180. Window 2120 can include a portion of a displayarea that contains information about used information 2030.

Window 2120 may include engineer identifier 2140 that identifies anindividual or a device used by the individual (e.g., developer 1910-1)that is associated with one or more seats of a software application. Forexample, Ned Gulley may be an engineer that is associated with a seatthat has been used within the last 30 days. Time in application 2150 mayinclude information that identifies usage information for a seat. Forexample, Ned may have used the software application for 220 hours in thelast 30 days.

Time writing code 2160 may include information that identifies an amountof time that an individual or device spent writing code or othermaterial (e.g., documentation). For example, Ned may have spent 10 hoursof the 220 hours that he was using the software application actuallywriting code. Time running code 2170 may include information thatidentifies an amount of time that was spent running code. For example,Ned may have spent two hours running code that he wrote during the last30 days. Time debugging code 2180 may include information thatidentifies an amount of time that was spent debugging code. For example,Ned may have spent 208 hours debugging code that he wrote during thelast 30 days.

Information displayed in user interfaces 2000 and 2100 may help thesupervisor make decisions about installed software applications and/orindividuals using the software applications. For example, the supervisormay determine that 250 of the 1200 installed seats (see FIG. 20) are notneeded because they have not been used within 90 days.

The supervisor working at manager 1920 may further use information fromuser interfaces 2000 and 2100 to make forward looking decisions, such aspurchasing decisions, hiring decisions, resource allocation decisions,etc. For example, the supervisor may decide that his group needsadditional copies of certain software based on high usage rates. Or, thesupervisor may determine that faster hardware and/or distributedprocessing capabilities are needed to reduce the amount of time requiredfor running code.

Other exemplary embodiments may perform other types of remote tasks onbehalf of a device. For example, an embodiment may publish code for atechnical computing application to the Web.

Exemplary Publishing to a Network

Assume that an engineering professor wants to teach his students aboutcontrol theory. The professor may wish to have the students focus on aparticular aspect of control theory, e.g., feedback, without becomingdistracted by other aspects of control theory. The professor maydetermine that computer based exercises will help the students learn thedesired material; however, the professor may not want the studentsspending time generating their own code for the exercises. The professormay decide that a good way for his students to learn is to interact withweb-based exercises that expose the students to all of the code used toimplement an exercise while only letting the students change selectedportions of the code, e.g., portions of the code that alter feedback ina control system.

The professor may interact with a system that allows the professor tocreate exercises that operate with a technical computing application(e.g., MATLAB software) that runs in dynamically typed programminglanguage (e.g., an array based language). The system may further allowthe professor to protect certain portions of the code (e.g., bypreventing editing, copying, etc.) while leaving other portions of thecode unprotected (e.g., by allowing editing, copying, etc.). The systemmay further allow the professor to identify protected portions of thecode and/or unprotected portions of the code using various techniques,such as highlighting, labeling, etc.). The system may allow theprofessor to publish an exercise that includes the identified codeportions, may allow students to interact with unprotected portions ofthe exercise, may produce results for the students based on the userinteractions with the unprotected portions, and/or may capture userinteractions so that the professor can determine whether the studentsunderstood the exercise.

FIG. 22 illustrates a system that publishes code using a network. System2200 may include network 120, students 2210-1 to N (collectivelystudents 2210), instructor 2220, and university server 2230. Students2210 may include devices that execute instructions. For example,students 2210 can be implemented via clients 110. In FIG. 22, students2210 may be used to access one or more code files prepared by instructor2220.

Instructor 2220 may include a device that executes instructions. In oneembodiment, instructor 2220 can include functionality of client 110 orserver 130. Instructor 2220 may be used to write code, protect code,label code (e.g., with annotations or instructions for students), sendcode, and/or receive code or other information (e.g., questions,answers, etc., from students 2210).

University server 2230 may include a device that executes instructions.In one embodiment university server 2230 may include functionality ofserver 130. In one embodiment, university server 2230 may provide codefrom instructor 2220 to students 2210 via network 120. University server2230 may include, web service 250, M-file 2240 and HTML file 2250. Webservice 250 may include logic that sends information to or receivesinformation from a destination. For example, web service 250 may sendcode written by instructor 2220 to students 2210 and/or web service 250may receive questions, answers, etc., from students 2210.

M-file 2240 may be a file that includes code written in the M languagefor use with MATLAB software. For example, instructor 2220 may write anexample problem for students 2210 in M. Instructor 2220 may receive aninput from a user (e.g., a professor teaching the class) that identifiesand/or modifies portions of the M-code. For example, some of the inputsmay identify a portion of M-code (e.g., one or more functions in thecode) as protected code. Protected code may include code that hasrestrictions placed on it by instructor 2220. For example, protectedcode may include restrictions that prevent certain types of activities,such as copying, editing, saving, displaying, etc. In FIG. 22, protectedcode may be visible on a display of student 2210-1, 2, or N; however,protected code may not be edited by student 2210-1, 2 or N.

Instructor 2220 may further receive a user input that identifies aportion of the M-code as unprotected code. Unprotected code may includecode that does not have restrictions placed on it. In an alternativeembodiment, unprotected code may include code having fewer restrictionsplaced on it as compared to a number and/or type of restrictions placedon a piece or section of protected code. In FIG. 22, unprotected codemay be edited by student 2210-1, 2 or N. For example, instructor 2220may label certain equations in the M-code as unprotected, where thelabeled equations control certain aspects of the M-code file.

Assume, for sake of example, that the professor wants his students tounderstand how certain activities may alter the performance of a system,such as a control system. In particular, the professor may want thestudents to understand how sample rates, feedback and/or dampingcontribute to stable and/or unstable performance of the system. Theprofessor may label code portions as protected portions when the codeportions do not contribute to, for example, a sample rate of the system.For example, the professor may protect code portions that create plotaxes, axes labels, that set initial conditions for the system, that varyfeedback for the system, etc. In contrast, the professor may label othercode portions as unprotected when these other code portions are relatedto the sample rate of the system. The students may be allowed tomanipulate values and/or operations in unprotected code portions tochange how the system operates.

University server 2230 may pass information about M-file 2240 to HTMLfile 2250 when protected and unprotected portions of M-file 2240 areidentified. HTML file 2250 may include information about the M-code codeor may include the M-code itself. HTML file 2250 may include code thatrenders a dynamic HTML page on a device, such as students 2210. Anembodiment of the HTML page may make use of a technical computingapplication (e.g., MATLAB software) to allow students 2210 to interactwith unprotected portions of M-file 2240. The HTML page may identifyprotected and/or unprotected portions of M-file 2240 using substantiallyany technique, such as shading, highlighting, contrasting colors,contrasting fonts, flickering fonts, symbols, audio signals, tactilesignals, etc. In one embodiment, a window may be placed aroundunprotected code and the unprotected code may be visible to a user. Incontrast, protected code may be blocked from view (e.g., by covering theprotected code with an opaque area), or protected code may be identifiedby a type of shading that differs from shading associated withunprotected code.

University server 2230 may pass HTML file 2250 to web service 250 fordisplay to students 2210. Information displayed to students 2210 via webservice 250 may be interactive so that user inputs can be received fromstudents 2210 and passed to web service 250. For example, web service250 may display an unprotected code portion on student 2210-1. A user ofstudent 2210-1 may enter a new value for a parameter in the unprotectedcode portion and web service 250 may pass the new value to an M codefunction operating on university server 2230. The function may beevaluated using the new value to produce an updated result. Web service250 may receive the updated result and may display the updated result tothe user via a display device on student 2210-1.

The embodiment of FIG. 22 can be modified to operate in other ways. Forexample, functions performed by university server 2230 may be offered asa service that allows full access to all of the M-code for a first priceand that allows access to a portion of the M-code for a second pricethat is lower than the first price. Subscribers may vary payments touniversity server 2230 depending on the number and/or type ofmodifications they wish to make to the M-file.

FIGS. 23-27 illustrate an example of an M-file that can be createdand/or published using exemplary embodiments.

FIG. 23 illustrates an exemplary page 2300 that can be displayed oninstructor 2220 using system 2200 (FIG. 22). For example, page 2300 maybe displayed to the professor via a browser running on instructor 2220.In FIG. 23, page 2300 may include code window 2310, instructions 2330and operational code 2340. Code window 2310 may include a region of page2300 where an M-file or another type of file is displayed to theprofessor. Embodiments of code window 2310 may use borders, shading,and/or other techniques to define a region of page 2300 for theprofessor.

Instructions 2330 may include text, graphics, symbols, audio, video,images, etc. Instructions 2330 may inform a user about informationincluded in code window 2310. For example, instructions 2330 may informa user (e.g., a student) about entering information into code window2310, may inform a user about lessons that should be learned byinteracting with code window 2310, may explain what other text,graphics, etc., in code window 2310 do, etc. Instructions 2330 mayfurther include information that identifies portions of code that shouldbe labeled as protected code and/or unprotected code.

Operational code 2340 may include text, graphics, symbols, audio, video,images, etc. In an embodiment, operational code 2340 may include textbased code that implements one or more functions that produce resultswhen executed. For example, in FIG. 23, operational code 2340 mayreceive user inputs, process user inputs, generate data values, plotdata values, display data values, etc.

Page 2300 may be created and/or edited using instructor 2220. When page2300 is complete, it can be sent to university server 2230 where page2300 can be formatted for publishing via web service 250. For example,page 2300 can include an M-file 2240 that implements one or morefunctions that generate results. M-file 2240 may be converted into anHTML file 2250 that can be published via web service 250.

FIG. 24 illustrates an exemplary published HTML page 2400. In anembodiment, HTML page 2400 can be displayed on students 2210 via browser220. HTML page 2400 can include window 2410, unprotected code 2420,input fields 2430, protected code 2440, and run button 2450.

Window 2410 may include a portion of a display area that includes userinputs, unprotected code 2420, and/or protected code 2440. Window 2410may be defined using borders and/or other techniques in an embodiment.

Unprotected code 2420 may include code that can be modified by a user.For example, unprotected code 2420 may include a portion of a publishedM-file that allows a user to enter values before running the M-file. Inan embodiment, unprotected code 2420 may include fields 2430 thatidentify a region where user inputs can be entered. The published M-filemay read values in fields 2430 when the M-file is run and may generateresults using read values.

Protected code 2440 may include a portion of the published M-file thatcannot be modified by a user. For example, protected code 2440 mayinclude code that reads values from fields 2430, that processes thevalues, that generates results based on the processed values, and thatplots the results on a display device or printed output, or that storesthe results in a storage device.

Run button 2450 may include logic that runs the published M-file usingvalues in fields 2430. For example, a user may enter a value of “7” fordt and a value of “100” for xMax into fields 2430 and may select runbutton 2450 via a pointing device. The published M-file may run and mayproduce one or more results based on the values “7” and “100”. Forexample, the published M-file may generate a plot.

FIG. 25 illustrates an exemplary page 2500 that can include a plotproduced when a published M-file is run. Page 2500 may be displayed tothe user via browser 220 in an embodiment. Page 2500 may include window2510, plot 2520, and legend 2530. Window 2510 may include a portion ofpage 2500 where one or more results of a published M-file can bedisplayed to a user. Plot 2520 may include one or more outputs generatedwhen a published M-file is run. For example, plot 2520 may includevalues for an original signal and a sampled signal plotted against an xand y axis. Legend 2530 may include information that identifies datadisplayed in plot 2520. For example, legend 2530 may identify which linerepresents the original signal and which line represents the sampledsignal.

A user may re-run the published M-file using different values todetermine how the operational code 2440 operates with the differentvalues. For example, in FIG. 26, display page 2600 may be displayed viabrowser 2220. The user may interact with unprotected code 2420 in page2600 and may enter new values in fields 2430. For example, the user maychange “7” to “10” for dt and may change “100” to “40” for xMax. Theuser may re-run the published M-file by selecting run button 2440.

The published M-file may run using “10” and “40” as inputs and mayproduce a result. FIG. 27 illustrates an exemplary plot that is producedwhen the published M-file is run with these updated inputs. For example,page 2700 may be displayed to the user when the published M-file is runwith “10” and “40” as input values. In an embodiment, information inplot 2520 may change when the published M-file is run with “10” and“40”. The embodiment may help a user make decisions based on resultsdisplayed in pages 2500 and 2700. For example, the user may determinewhether the published M-file produces more desirable results with “7”and “100” as input values or with “10” and “40” as input values.

In an embodiment, information entered by the user may be sent back touniversity server 2230 and/or instructor 2220. For example, theprofessor may determine whether his students completed an entireexercise, obtained correct results, etc., by examining informationreceived from pages 2400, 2500, 2600 and/or 2700.

Exemplary Device Architecture

FIG. 28 illustrates an exemplary architecture for implementing client110 or server 130. It will be appreciated that a hardware implementationof UE 270, farm manager 320, and/or other devices may be similarlyconfigured. As illustrated in FIG. 28, architecture 2800 may include abus 2810, a processor 2820, a memory 2830, a read only memory (ROM)2840, a storage device 2850, an input device 2860, an output device2870, and a communication interface 2880.

Bus 2810 may include one or more interconnects that permit communicationamong the components of client 110/server 130. Processor 2820 mayinclude any type of processor, microprocessor, or processing logic thatmay interpret and execute instructions (e.g., an FPGA, a applicationspecific integrated circuit (ASIC), an analog processing device, aquantum-based processing device, etc.). Processor 2820 may include asingle device (e.g., a single core) and/or a group of devices (e.g.,multi-core).

Memory 2830 may include a random access memory (RAM) or another type ofdynamic storage device that may store information and instructions forexecution by processor 2820. Memory 2830 may also be used to storetemporary variables or other intermediate information during executionof instructions by processor 2820.

ROM 2840 may include a ROM device and/or another type of static storagedevice that may store static information and instructions for processor2820. Storage device 2850 may include a magnetic disk and/or opticaldisk and its corresponding drive for storing information and/orinstructions.

Input device 2860 may include any mechanism or combination of mechanismsthat permit an operator to input information to a device that includesarchitecture 2800, such as a keyboard, a mouse, a touch sensitivedisplay device, a microphone, a pen-based pointing device, and/or abiometric input device, such as a voice recognition device and/or afinger print scanning device. Output device 2870 may include anymechanism or combination of mechanisms that outputs information to theoperator, including a display, a printer, a speaker, etc.

Communication interface 2880 may include any transceiver-like mechanismthat enables a device to communicate with other devices and/or systems,such as client 110, service provider 140, UE 270, farm manager 320, etc.For example, communication interface 2880 may include one or moreinterfaces, such as a first interface coupled to network 120 and/or asecond interface coupled to another device, such as farm manager 320.Alternatively, communication interface 2880 may include other mechanisms(e.g., a wireless interface) for communicating via a network, such as awireless network. In one implementation, communication interface 2880may include logic to send code to a destination device, such as adestination device that can include general purpose hardware (e.g., apersonal computer form factor), dedicated hardware (e.g., a digitalsignal processing (DSP)), etc.

A device that includes architecture 2800 may perform certain functionsin response to processor 2820 executing software instructions containedin a computer-readable medium, such as memory 2830. A computer-readablemedium may be defined as one or more memory devices and/or carrierwaves. In alternative embodiments, hardwired circuitry may be used inplace of or in combination with software instructions to implementfeatures consistent with principles of the invention. Thus,implementations consistent with principles of the invention are notlimited to any specific combination of hardware circuitry and software.

Exemplary Policy-Based Dispatch of Requests

Exemplary embodiments can be configured to dispatch requests accordingto policies. For example, a client, such as client 110, may make arequest for processing activities, storage service operations,application level services, etc. An embodiment of the invention canintelligently handle the requests according to one or more policies thatare used to determine how to handle the request. For example, a policymay be used to identify the most appropriate remote processing resourceto handle a processing request from the client given certainconstraints, such as a maximum latency for obtaining a result, a costthreshold, an accuracy threshold, a security constraint, etc.

FIG. 29 illustrates a system for intelligently dispatching requests froma client to one or more remote devices. System 2900 can include client110, network 120, server 130, display 210, LAN 260, input device 2905,remote storage device 2930 and remote processors 2940-1, 2, to N.

Client 110, network 120 and server 130 may be devices as described inconnection with FIG. 1; and, display 210 and LAN 260 may be devices asdescribed in connection with FIG. 2. Client 110 may include applicationprogramming interface (API) 2910-1, and other devices in system 2900 mayinclude similar APIs 2910-2, 3, 4, and/or 5 (generally referred to asAPI 2910). API 2910 may be comprised of software that invokes a service.For example, API 2910-1 may invoke a service that performs processing onbehalf of client 110, while another API, such as API 2910-4 may invoke aservice that stores information on behalf of a requesting device. API2910 may be on a device that invokes the API, may be remote with respectto a device that invokes the API, or API 2910 may be sent to arequesting device so that the requesting device can invoke the APIlocally once received.

In system 2900, API 2910 may dynamically determine where a softwareservice should be run to satisfy a request. System 2900 may use one ormore policies with API 2910 to determine where to run a software serviceon behalf of the requesting device. For example, client 110 may use API2910-1 for requesting a processing service. API 2910-1 may be used todynamically determine whether a local service (i.e., a processingservice resident on client 110) should be used or whether a remoteprocessing service should be used. If a remote service should be used,API 2910-1, alone or in combination with other software in system 2900,may determine a particular remote processing resource for performing theservice.

In an embodiment, the APIs 2910 may be selected according to policiesthat can include, but are not limited to, a security policy, a costpolicy, a bandwidth policy, a state policy, a latency policy, aconfiguration policy, a location policy, a quality-of-service policy, atopology policy, an affiliation policy, a licensing policy, a rightspolicy an accuracy policy, etc.

For example, a security policy may require that resources used tosatisfy the request must meet a certain security threshold, e.g., mustbe on a certain type of network, that processing resources areassociated with certain entities, that the processing resources providean uncontaminated environment to the requesting device, etc. A costpolicy may include pricing metrics that cannot be exceeded by resourcesprocessing a request, e.g., a cost per mega-flop of CPU time, a cost permega-byte of storage, an access cost for a resource, etc.

A bandwidth policy may determine a throughput for a network or deviceassociated with performing processing on behalf of a requesting device,e.g., a network connection may need to have a certain guaranteedbandwidth to comply with the policy. A state policy may identify a statethat a processing resource needs to satisfy in order to performprocessing on behalf of a requesting device, e.g., a processing devicemay need to establish a processing environment from scratch beforeprocessing the request to eliminate chances that old information isresiding in the environment when the request is processed.

A latency policy may identify a time interval, within which a resultmust be produced, received, etc., once a request is dispatched to aprocessing resource. A configuration policy may identify a particularhardware, software, or combination of hardware and softwareconfiguration that must be present on a processing resource operating ona request.

A location policy may indicate that processing resources need to be at acertain location (e.g., a geographic location) in order to be used toprocess the request. A quality-of-service policy may identify a minimumthreshold for the quality-of-service of a network, device, etc., used toprocess a request. A topology policy may identify one or more networktopologies (e.g., that may include devices in a cloud computing network)or characteristics of the topologies that should be satisfied by devicesand/or networks used to process a request. Example characteristics mayinclude, but are not limited to, proximity between two or more elementswithin the topology as measured by, for example, network bandwidth,latency, and/or network addresses (e.g., network domain, networksub-domain, etc.).

An affiliation policy may identify affiliations for entities or devicesused to process a request. For example, an affiliation policy mayindicate that only processing resources associated with an educationalinstitution can be used to process a request. A licensing policy mayindicate that processing resources need to comply with certain licensesin order to process a request. For example, processing devices may needto have valid licenses for a technical computing environment in order tooperate on a request received from a client.

A rights policy may identify certain legal rights that need to becomplied with by processing resources operating on a request. Forexample, a rights policy may indicate that processing resources need tosatisfy patent, copyright, trademark, export compliance, etc., laws withrespect to hardware and/or software used to process a request. Anaccuracy policy may identify a threshold that identifies a minimumaccuracy that processing resources must satisfy in order to operate on arequest. Other embodiments of the invention may employ one or more othertypes of policies, with or without the policies discussed above, withoutdeparting from the spirit of the invention.

Server 130 may include an API repository 2920 that stores APIs for usein system 2900. For example, when client 110 requests a service andclient 110 does not have an appropriate API locally available, an API,such as API 2910-3, may be retrieved from API repository 2920 and madeavailable to client 110. Client 110 may use API 2910-3 to access therequested service.

Remote storage device 2930 may provide remote storage services to client110. Remote storage device 2930 may include API 2910-4 that may berequired to provide storage services to client 110 in an embodiment. Inanother embodiment, server 130 may retrieve an API from API repository2920 and may provide it to client 110 or to remote storage device 2930so that client 110 can access remote storage services. In still anotherembodiment, client 110 may have an appropriate API in local storage andmay use the API to access storage services.

System 2900 may include one or more remote processors 2940-1, 2940-2 to2940-N (generally remote processors 2940) that perform remote processingoperations on behalf of a requesting device, such as client 110 orserver 130. Remote processors 2940 may include APIs, e.g., API 2910-5,for accessing remote processing services, or APIs may be storedelsewhere in system 2900. In an embodiment, remote processor 2940-1 maymake API 2910-5 available to client 110 when client 110 requests aremote processing service. API 2910-5 may determine which ones of remoteprocessors 2940 are most appropriate for providing a requestedprocessing service to client 110 based on a remote processing policyassociated with system 2900.

Exemplary Processing for Policy-Based Dispatch of Requests

FIG. 30 illustrates exemplary processing for performing policy-baseddispatching of requests for services. For example, the acts of FIG. 30may be performed by devices illustrated in FIG. 29 according to anembodiment of the invention.

Referring to FIG. 30, a task may be identified (act 3005). For example,client 110 may have a processing task, a storage task, a communicationtask, application level task, etc., that needs to be performed. In anembodiment, the task may be performed using a device that provides aservice on behalf of the client, where the device may be local (e.g.,performed on client 110) or remote with respect to client 110. Once thetask is identified, a determination may be made as to whether adequatelocal resources are available on client 110 for performing the task (act3010). If adequate local resources are available, the task may beprocessed locally using a service resident on client 110 (act 3015).However, if adequate local resources are not available, an availableservice may be dynamically identified (act 3020). In an embodiment, whena task is processed locally at act 3015, another service may berequested via path 3025 and dynamically identified via act 3020.

Once a service is identified, a determination may be made as to whetheran API is available for the identified service (act 3030). When an APIfor the required service is available, the API is loaded (act 3035). Incontrast, when an API is not available, for example locally at client110, an appropriate API may be retrieved (act 3040). The retrieved APIat act 3040 may then be loaded (act 3035).

The loaded API may be used to dispatch a request that includes the taskto an identified service (act 3045). For example, a task may be sentfrom client 110 to remote storage device 2930 using server 130. Remotestorage device 2930 may provide a storage service to client 110. In anembodiment, remote storage device 2930 may provide a confirmationmessage indicating that the storage request was satisfied. Client 110may receive the confirmation (identified as a result in FIG. 30) vianetwork 120 (act 3050).

Exemplary Technique for Dynamically Scaling Resources

Embodiments of the invention can be configured to dynamically scaleremote processing resources according to current processing demands andaccording to predicted processing demands. For example, an embodimentmay use predictive models that accept current processing loads as aninput and use other information, such as historical processing data,along with one or more algorithms to generate estimates of futureprocessing loads. These future processing loads may be for a determinedtime interval, such as a number of seconds, minutes, hours, days, etc.

By way of example, a number of clients 110 may be using remoteprocessing resources to perform calculations. The clients may be placinga current demand on these resources and the current demand may be usedas an input to a predictive model that uses the time of day and dateinformation to predict remote processing loads for the next hour. Themodel may produce a result that indicates the current demand will likelyincrease by 25% within the next hour. The model result may be used by ascheduler operating in server 130 to bring additional remote processingresources online and to make the additional resources available toclients 110. The additional resources may include enough processingdevices to handle a processing demand increase of 25% without adverselyimpacting response times, processing speeds, processing accuracy, etc.,for clients 110.

FIG. 31 illustrates exemplary processing that may be used to dynamicallyscale processing resources using predictive algorithms. A predictivemodel may be initiated (act 3105). The predictive model may beconfigured to provide a processing power buffer (e.g., a certain amountof excess processing capability) to an environment that providesdistributed processing capabilities to clients 110.

An initial resource buffer may be created using outputs from thepredictive model (act 3110). For example, a buffer of 5% may bemaintained, where the 5% indicates that enough processing resources areprovided so that no more than 95% of available processing resources arebeing used at a given time. Embodiments may establish buffers based onvarious parameters associated with a distributed processing environment.For example, a buffer may be established based on overall processingload on a system, based on particular types of processing loads (e.g.,image processing loads, cell processing loads, etc.). In addition, abuffer may represent an aggregation of two or more different types ofbuffers that individually may be established according to differentsystem parameters. Buffers may further be based on hardware resourceloads, software resource loads, availability of specialized hardwareresources, availability of specialized software resources (e.g.,software applications, software toolboxes, operating systemconfigurations, virtual machine configurations, etc.). Still further,buffers may be established or modified based on a rate-of-change for aload on a system. For example, buffers may account for rates-of-changefor a number of users, types of processing (e.g., image processing, cellprocessing, filtering, etc.), system latencies, quality-of-service,accuracies of results, device failures, errors, etc., over a determinedinterval, such as a number of seconds, minutes, hours, days, etc.

Processing loads and/or other activities may be monitored in theenvironment using the predictive model (act 3115). Information relatedto the monitored activities may be fed to the predictive model to updatethe model with current information about demands being placed on theenvironment (act 3120).

The processing may determine whether a current buffer size is adequatebased on a result from the updated predictive model (act 3125). When thebuffer size is adequate, no change to the buffer size may be made (act3130). However, when the current buffer size is not adequate at act3125, a determination may be made as to whether the current buffer sizeis too small (act 3135). When the current buffer size is too small,additional resources may be brought online (act 3140). In contrast, whenthe current buffer size is too large, some resources may be renderedunavailable (e.g., taken offline) (act 3145).

FIG. 32 illustrates an embodiment that can be used to dynamically scaleresources in a distributed processing environment. The embodiment ofFIG. 32 may include software modules configured to perform variousoperations associated with dynamically scaling resources. The modules ofFIG. 32 may be generally grouped into machine resource manager functionslocated along the left side of FIG. 32 and directory lookup servicefunctions located along the right side of FIG. 32. Other implementationsfor dynamically scaling resources may be configured in other wayswithout departing from the spirit of the invention.

Referring to FIG. 32, worker provider service 3205 may be a genericinterface that describes lifecycle events for managing workers, such asworkers used to perform remote processing activities on behalf of aclient. For example, worker provider service 3205 may reserve a worker,may recycle a worker (e.g., by returning the worker to a pool orresources for performing remote processing and/or by cleaning the workerfor reuse), may store or retrieve policies associated with a worker,etc. In an embodiment of the invention, workers that perform remoteprocessing may be MATLAB workers or MATLAB-compatible workers and mayoperate as part of a computing cloud that is configured to performtechnical computing operations on behalf of clients.

Abstract worker provider service 3210 may be a base class thatimplements reusable methods of the worker provider service interface3205. In an embodiment, the abstract worker provider service 3210 mayimplement a subset of the methods defined in worker provider service3205.

Worker provider chain implementation 3215 may include an implementationof worker provider service 3205 that aggregates several worker providerimplementations 3215. In an embodiment, worker provider implementations3215 may include logic needed for using a heterogeneous collection ofworkers. The heterogeneous collection of workers may include both localand cloud based workers.

Worker provider local implementation 3220 may be an extension of theabstract worker provider service 3210 that is suitable for managing acollection of local workers. For example, in an embodiment, localworkers may be workers local with respect to an internal network ormachine (i.e., may not be cloud based).

Worker provider cloud implementation 3225 may include an implementationof the worker provider service interface 3205 that embodies logic formanaging life cycle events of workers that run in a computing cloud. Inan embodiment, the workers may be MATLAB workers or MATLAB-compatibleworkers and the computing cloud may be a commercially available cloud ormay be a cloud customized for one or more applications. In theembodiment of FIG. 32, an element of the logic embodied in workerprovider cloud implementation 3225 can include the implementation of anevent based (including time driven) mechanism for creating new workers,checking on the health (including network accessibility, validity of thetechnical computing environment, etc.) of workers and/or recycling“sick” workers, e.g., workers that fail to meet health requirements ofthe system

Scalability strategy interface 3227 may include an interface thatdefines methods (e.g., key methods) invoked during dynamic scalingdecision making, e.g. poll(workerLookupService, rules, cloudService),recycle(workerLookupService, rules, machineId). Scalability strategyinterface 3227 allows the worker provider implementation 3215 or 3225 toapply different strategies based on configuration properties or otheraspects of a system.

Scalability strategy implementation 3235 may include an implementationof scalability strategy interface 3227. Alternative implementations ofscalability strategies may use different cloud resource providers,evaluate respective rules at different rates, selectively apply somerules and not others, etc., without departing from the spirit of theinvention.

Worker provider rules 3230 may include a set of policies that areapplicable during scalability strategy evaluation. Examples of policiesmay include, but are not limited to, setting dynamic scaling on/off,terminating sick machines, not terminating “n” sick machines so thesemachines can be examined, adjusting strategy algorithms based on time ofday, day of week, etc.

Machine worker lookup service 3240 may include an interface thatdescribes a service which allows clients to lookup specific workers ordiscover generically described workers and associated technicalcomputing resources. These technical computing resources may includemachines (e.g. virtual machines in a cloud computing environment). In analternative implementation, the workers may be MATLAB workers operatingin a cloud computing environment.

Machine worker lookup service implementation 3245 may include animplementation of the Machine Worker Lookup Service. Machine workerlookup service implementation 3245 may be responsible for providinglookup and discovery services for the collection of all resources neededto support a technical computing environment worker (e.g., worker DAOinterface 3250). In an implementation, machine DAO 3255 may represent asingle type of resource needed to support worker interface 3250.

Worker DAO 3250 may include an interface that defines a data accessobject (DAO) that manages a collection of worker resources. In animplementation, the worker resources may be MATLAB workers. In oneimplementation, the MATLAB Workers may be dependent on a collection oftechnical computing resources, an example of which is machine technicalcomputing resource DAO (3255).

Machine/technical computing resource DAO 3255 may include an interfacethat defines a data access object that manages a collection of computingresources required by Worker DAO 3260. In an implementation, the workerDAO may be a MATLAB worker DAO.

Worker DAO implementation 3260 may include an implementation of workerDAO interface 3250. Machine DAO implementation 3265 may include animplementation of the machine DAO interface 3255.

Worker selector DO 3270 may include a data object used to genericallydescribe a type of worker that meets a set of specified characteristics.In an alternative implementation, worker selector DO 3270 may describe atype of worker that satisfies a specific MATLAB Worker instance.

The embodiment illustrated in FIG. 32 and discussed above isillustrative and other embodiments may include more software modules,fewer software modules and/or software modules that differ from thoseillustrated in FIG. 32 and/or discussed above.

Exemplary Technique for Maintaining State

Exemplary embodiments may be configured to maintain a state of anenvironment in which a user performs computing operations. For example,a user may be working within a technical computing environment toperform computations associated with a model of a dynamic system. Theenvironment may include data, plots, instructions, a workspace forstoring variables and other information, etc. This information maycollectively determine a state for the environment in which the useroperates. In some embodiments, this state may change over time. Forexample, the environment may have a first state when the model is at afirst time step during execution and a second state when the model is ata second time step.

Conventional environments may not allow a user to resume computingoperations from where the user left off because the conventionalenvironment may not be able to duplicate the state of the environmentthat was present when the user previously logged off of the environment.The conventional environment may further pose problems when, forexample, the user was initially working on a desktop machine, loggedoff, and then tried to log in using a wireless device, such as aniPhone™ (made by Apple Inc.). The conventional environment may not beable to synchronize the state of the desktop environment with the iPhonefor several reasons, such as but not limited to, formatincompatibilities between the wireless device and desktop device,differences in processing capabilities between the wireless device andthe desk top device (e.g., the wireless device may not be able to handleall of the information making up the state of the desktop device),licensing issues between software in the desktop environment andsoftware on the wireless device, etc.

FIG. 33 illustrates exemplary processing for maintaining deviceindependent state for a computing environment, such as a technicalcomputing environment. The computing environment may be initiated (act3305). For example, a user may double click an icon on a desktop of acomputing display and may launch a technical computing environment thatallows the user to perform technical computing tasks.

The technical computing environment may receive user inputs (act 3310)and may perform processing activities based on the received inputs (act3315). For example, the user may enter a command to process data and thetechnical computing environment may retrieve the data from storage andmay process the data using commands specified by the user. The technicalcomputing environment may store states for the environment periodically(act 3320). For example, the state may include a most recent instructionentered by the user, stored variables and/or data, plots generated bythe user, display window configurations, keyboard shortcuts, etc. Statemay further include, among other things, information about an operationperformed using the technical computing environment, an output, a sampletime (e.g., a sample time used by a model executing in the environment),an event (e.g., a user initiated event or a device initiated event), aconfiguration (e.g., a configuration of the environment or a device), aflag, an error message, a device identifier (e.g., a network address,host ID, etc.), an operating system identifier, etc.

In one implementation, the user may log off of a device, such as client110, on which the processing was performed once the state is stored inact 3320. In another embodiment, the device (e.g., client 110) mayremain running once the state is stored in act 3320. For example, theclient may continue processing data using the technical computingenvironment.

A user may be detected (act 3325). For example, the user may have walkedaway from client 110 to attend a meeting and may be logging into thetechnical computing environment from a wireless device, such as aniPhone, or the user may log on from a publicly available computer. Thetechnical computing environment may obtain device information for thedevice that the user is currently associated with (act 3430).

The technical computing environment may load state information frommemory (act 3335). For example, the technical computing environment mayload a most recent state that represents a current state of theenvironment. The processing may determine whether the loaded state is astatic state or an advancing state (act 3340). For example, a staticstate may be a state that is not changing, such as when a user loggedout of the technical computing environment and left nothing running. Inthis situation, the retrieved state is the most recent state and may beprovided to the user via the wireless device (act 3345). The processingmay convert the state into a format compatible with the wireless devicebefore sending the state information to the user.

When the status of the state is advancing, a current state may beaccessed (act 3350). For an advancing state, the current state may beretrieved from volatile memory (e.g., RAM) or from non-volatile memory(e.g., hard disk) depending on the speed of the memory devices, the rateat which the state is changing, etc. The current state may be providedto the user via the wireless device (act 3355). After act 3345 or 3355,processing flow may return to act 3310 and the technical computingenvironment may receive additional user inputs. To the user, the stateobserved via the wireless device may be identical to the state that theuser would observe if the user were at the desktop device. When the userlogs off of the wireless device and logs back onto the desktop device,the state may appear just as it would if the user remained logged in viathe wireless device.

Many alternative embodiments are possible based on the foregoingdescription. Examples of some alternative embodiments are, but are notlimited to those described below.

Exemplary Alternative Embodiments

For example, a first alternative embodiment may host a collaborativecoding environment that encourages a group of programmers to developquality code that can be used in remote processing applications, such asremote processing applications that use one or more TCEs. For example, aweb site may allow programmers to submit remote processing code that canbe tested, edited, enhanced, etc., by other programmers that in turnpost the tested, edited, enhanced, etc., code to the web site. Stillother programmers may use or may make enhancements to the code tofurther improve the code. Collaborating programmers and/or end users mayrate pieces of code in terms of parameters, such as speed, accuracy,compactness, etc., to allow still other users to make informed decisionsabout a piece of collaboratively developed code.

A second alternative embodiment may provide integration logic inconjunction with remote processing code to allow integration of remoteprocessing code with other applications on a device, e.g., client 110.For example, a piece of integration logic may include software thatallows a data acquisition application running on client 110 to exchangeacquired data with remote processing code operating locally on client110. The remote processing code may send the acquired data to two ormore processing devices, such as UEs that process the data using adynamically typed language, and may receive a result from the UEs. Theremote processing code may send the result to a display applicationrunning on client 110 so that the result can be displayed to a user ofclient 110.

A third alternative embodiment may include a statistics module thatoperates with server 130, where the statistics module acquiresinformation about users that participate in remote processingactivities. For example, server 130 may acquire information aboutproblems (e.g., size, complexity, etc.), data, user locations, userdemographics, etc., when the users are engaged in remote processingusing server 130. Server 130 may use the statistics to directdevelopment efforts, debugging efforts, marketing efforts, purchasingefforts (e.g., to determine what types of processing hardware to buy),etc.

A fourth alternative embodiment may provide remote processing serviceson a tiered basis, where different tiers have different cost structures.For example, server 130 may provide a first tier to a user where thefirst tier allows the user to use a fixed number of UEs 270 for remoteprocessing. The first tier may have a first cost associated with it(e.g., a cost per month, a cost per job, etc.). Server 130 may provide asecond tier to another user where the second tier allows the user to usea number of UEs 270 that is determined based on the complexity of aproblem. The second tier may have a variable cost associated with it,where the cost is determined by the number of UEs 270 used for aparticular processing task.

A fifth alternative embodiment may include a server 130 that performspre-computing tasks based on a user's past behavior, based on a type ofproblem operated on by server 130, or based on other parameters. Forexample, server 130 may know that the user typically performs remoteprocessing tasks that generate certain constants and/or otherinformation. When the user initiates a session, or performs activitiesprior to remote processing activities, server 130 may pre-compute theconstants so that they are ready when the user begins remote processing.Pre-computing constants and/or other information on behalf of the usermay reduce the amount of time taken to operate on the user's problemand/or may reduce the amount of remote processing resources required tosolve the user's problem.

A sixth alternative embodiment may run a first TCE and a second TCE witha timing interval between them, where the timing interval allows one TCEto compute a result before the other TCE computes the result. Forexample, a user may run a problem on a first TCE and a second TCE wherethe first TCE runs ten seconds ahead of the second TCE. If the first TCEencounters an error or crashes, the second TCE may have debugging logicturned on so that the second TCE is running in debug mode when thesecond TCE executes the code portion that caused the error or crash. Thesecond TCE may provide detailed debugging information that could not beobtained from the first TCE to allow the user to quickly and accuratelydebug incorrect code.

A seventh alternative embodiment may include a real-time testingenvironment that includes a client and a number of UEs. The UEs mayfurther be configured with various types of hardware, such asspecialized test hardware. A client may select a particular UE based onthe type of real-time testing that is being performed. For example, afirst UE may have a first test device attached thereto. The client maysend an instruction and/or data to the first UE when the client desiresto have real-time testing performed on the first test device. Real-timetest environments may include other types of hardware, such as targetdevices and/or code generators for creating code that can be run on thetarget devices. The client and the selected UE may exchangebi-directional messages while the UE performs real-time testing onbehalf of the client.

An eighth alternative embodiment may provide games, puzzles, etc., usingserver 130 and/or remote processing devices, such as UEs 270, clusters330 and 530, etc. For example, server 130 may host a game where thewinner is the participant that can solve a problem using the fewestlines of code. This contest may operate like a golf game where thefewest strokes (here lines of code) identifies the winner.Alternatively, server 130 can post puzzles that participants try tosolve using remote processors. Other embodiments may allow users to postcontests, puzzles, etc., from one or more clients 110.

A ninth alternative embodiment may implement TCE 290 using one or moretext-based products. For example, a text-based TCE 290, may beimplemented using products such as, but not limited to, MATLAB® by TheMathWorks, Inc.; Octave; Python; Comsol Script; MATRIXx from NationalInstruments; Mathematica from Wolfram Research, Inc.; Mathcad fromMathsoft Engineering & Education Inc.; Maple from Maplesoft; Extend fromImagine That Inc.; Scilab from The French Institution for Research inComputer Science and Control (INRIA); Virtuoso from Cadence; or Modelicaor Dymola from Dynasim. The text-based TCE may support one or morecommands that support remote processing using one or more UE's 270.

A tenth alternative embodiment may implement TCE 290 in agraphically-based TCE 290 using products such as, but not limited to,Simulink®, Stateflow®, SimEvents™, etc., by The MathWorks, Inc.; VisSimby Visual Solutions; LabView® by National Instruments; Dymola byDynasim; SoftWIRE by Measurement Computing; WiT by DALSA Coreco; VEE Proor SystemVue by Agilent; Vision Program Manager from PPT Vision; Khorosfrom Khoral Research; Gedae by Gedae, Inc.; Scicos from (INRIA);Virtuoso from Cadence; Rational Rose from IBM; Rhopsody or Tau fromTelelogic; Ptolemy from the University of California at Berkeley; oraspects of a Unified Modeling Language (UML) or SysML environment. Thegraphically-based TCE may support remote processing using one or moreUE's 130.

An eleventh alternative embodiment may be implemented in a language thatis compatible with a product that includes a TCE, such as one or more ofthe above identified text-based or graphically-based TCE's. For example,MATLAB (a text-based TCE) may use a first command to represent an arrayof data and a second command to transpose the array. Another product,that may or may not include a TCE, may be MATLAB-compatible and may beable to use the array command, the array transpose command, or otherMATLAB commands. For example, the product may use the MATLAB commands toperform parallel processing using one or more UEs 270.

A twelfth alternative embodiment may be implemented in a hybrid TCE thatcombines features of a text-based and graphically-based TCE. In oneimplementation, one TCE may operate on top of the other TCE. Forexample, a text-based TCE (e.g., MATLAB) may operate as a foundation anda graphically-based TCE (e.g., Simulink) may operate on top of MATLABand may take advantage of text-based features (e.g., commands) toprovide a user with a graphical user interface and graphical outputs(e.g., graphical displays for data, dashboards to monitor UE 270, etc.).

A thirteenth alternative embodiment may employ a copy of TCE 290 on bothclient 110 and UE 270, where the TCEs allow workspace sharing. Forexample, client 110 may maintain a first workspace with a copy of TCE290 running on client 110 and UE 270 may maintain a second workspacewith a copy of TCE 290 running thereon. Client 110 may create variablesin the first workspace and UE 270 may request the variables from thefirst workspace and may store the variables in the second workspace whenperforming parallel processing. UE 270 may further make variables in thesecond workspace available to another UE (e.g., UE 270-1), client 110,farm manager 320, etc., to further facilitate parallel processing onbehalf of client 110 and/or another device. Alternatively, only client110 may have a workspace, and client 110 may communicatively couple theworkspace to UE 270 so that UE 270 can access information therein.

A fourteenth alternative embodiment may allow client 110 to performparsing operations to facilitate remote processing for, by way ofexample, a model on client 110. For example, client 110 may run aSimulink model that includes a number of subsystems. Client 110 mayparse the model based on the subsystems and may send a first subsystemto a first UE and may send the second subsystem to a second UE, wherethe first and second UE's are each configured as MATLAB-UE's (e.g., byrunning a version of MATLAB on each UE). The first and second UE's mayprocess their respective subsystems and may request variables fromclient 110 or from other devices (e.g., from server 130). For example,client 110 may have a sharable workspace that is communicatively coupledto the first and second UE to allow the UE's access to variables neededto perform processing. The first and second UE's may each produce aresult file that is sent back to client 110, where client 110 combinesthe files and performs a compilation operation to compile the model.Alternatively, the first and second UE's may send the result files to athird UE, where the third UE combines the result files and compiles themodel on behalf of client 110.

A fifteenth alternative embodiment may perform remote (e.g., parallel)processing using stream processing techniques. For example, a first UEmay perform code generation for a model received from client 110. Thefirst UE may send a result to a second UE and the second UE may performa portion of a build operation on the generated code. The second UE maysend its result to a third UE that performs a compile operation on theresult received from the second UE. The third UE may generate a resultthat includes the compiled code and may send the result to client 110.

A sixteenth alternative embodiment may perform parallel processing onbehalf of a client using one or more commercial computing grids. Forexample, client 110 may send a request for remote processing to a serverthat operates with a commercial computing grid, where the commercialcomputing grid provides remote processing resources to clients for a fee(e.g., a fee based on an amount of processing resources used by client110). The commercial computing grid may contain one or more clustersthat can be associated with one or more providers (e.g., computingservice providers). Client 110 may rent time (e.g., during a rentalperiod) on the grid and may perform remote processing during the rentalperiod. For example, client 110 may exchange bi-directional messageswith one or more clusters within the grid, one or more devices within acluster, etc., during the rental period. Rented resources may requeststate information from client 110 (e.g., information about availablememory, information about variables, information about programming code,information about functions, etc.). Rented resources may also taskclient 110 to perform operations (e.g., processing activities, sendinginformation, etc.) on behalf of the rented resources. For example, adevice in a cluster may request that client 110 perform processing toconvert a data value from a first format to a second format beforeclient 110 sends the data value to the requesting device. Client 110 andthe cluster(s) used to perform remote processing on behalf of client 110may operate in a homogeneous or heterogeneous configuration depending onparticular implementations used to perform remote processing.

In a seventeenth alternative embodiment, a first UE can act as a clientwith respect to a second UE, a third UE, etc. For example, client 110may request that the first UE perform parallel processing. Client 110and the first UE may exchange bi-directional messages while the first UEperforms remote processing. The first UE may determine that it can useadditional remote processing resources from a second UE and a third UE.The first UE may perform bi-directional communication with the second UEand the third UE to allow the second UE and third UE to assist the firstUE with performing remote processing on behalf of client 110.Configurations can include substantially any number of clients and UE'sarranged in any type of hierarchical relationship without departing fromthe spirit of the invention.

In an eighteenth alternative embodiment, clients 110 may be able toselectively become network hosts for versions of TCE 290 residingthereon. For example, client 110 may download a version of TCE 290 andcode to perform remote processing using server 130. Client 110 mayperform a remote processing task using, for example UE 270 and mayobtain a result. Client 110 may wish to make its TCE version availablefor another client to use. Client 110 may host its TCE 290 and client110-N may make use of TCE 290 to perform standalone processing or toperform remote processing using another device.

Still other alternative implementations are possible consistent with thespirit of the invention.

Embodiments described herein produce useful and tangible results. Forexample, tangible results (e.g., results that can be perceived by ahuman) can be produced when a result is displayed to a user, when adevice makes a sound, vibrates, performs an operation (e.g., moves,interacts with a person, etc.), etc. Useful results may include, but arenot limited to, storage operations, transmission operations (e.g.,sending information or receiving information), display operations,displacement operations, etc. Tangible and/or useful results may includestill other activities, operations, etc., without departing from thespirit of the invention.

CONCLUSION

Implementations may provide devices and techniques that perform remoteprocessing on behalf of a device over a network.

The foregoing description of exemplary embodiments of the inventionprovides illustration and description, but is not intended to beexhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the invention. Forexample, while a series of acts has been described with regard to FIG.10-12, the order of the acts may be modified in other implementationsconsistent with the principles of the invention. Further, non-dependentacts may be performed in parallel.

In addition, implementations consistent with principles of the inventioncan be implemented using devices and configurations other than thoseillustrated in the figures and described in the specification withoutdeparting from the spirit of the invention. Devices and/or componentsmay be added and/or removed from the implementations of FIGS. 1, 2,3A-3C, 5-7, 13A-E, 14, 19, 22 and 28 depending on specific deploymentsand/or applications. Further, disclosed implementations may not belimited to any specific combination of hardware.

Further, certain portions of the invention may be implemented as “logic”that performs one or more functions. This logic may include hardware,such as hardwired logic, an application-specific integrated circuit, afield programmable gate array, a microprocessor, software, wetware, or acombination of hardware and software.

No element, act, or instruction used in the description of the inventionshould be construed as critical or essential to the invention unlessexplicitly described as such. Also, as used herein, the article “a” isintended to include one or more items. Where only one item is intended,the term “one” or similar language is used. Further, the phrase “basedon,” as used herein is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

The scope of the invention is defined by the claims and theirequivalents.

What is claimed is:
 1. One or more computer-readable media holdingexecutable instructions that when executed on processing logicdynamically dispatch a request associated with a technical computingenvironment, the media holding one or more instructions for: identifyinga request for a service provided by one or more of a plurality of remotedevices in a distributed processing environment that includes one ormore technical computing environments; accessing a data structureholding a plurality of policies for dynamically determining at least oneof the plurality of remote devices for providing the service to a devicemaking the request, where: the at least one of the plurality of remotedevices is available and configured to provide the service, and theservice is used to satisfy the request; selecting at least one policyfrom the plurality of policies in the data structure, the at least oneselected policy including one or more of: a security policy, a costpolicy, a bandwidth policy, a state policy, a latency policy, aconfiguration policy, a location policy, a quality-of-service policy, atopology policy, an affiliation policy, a licensing policy, a rightspolicy, and an accuracy policy; applying the selected at least onepolicy to the request; identifying at least one of the plurality ofremote devices that complies with the selected at least one policy,where complying with the policy indicates that the at least one of theplurality of remote devices will satisfy the request; and dynamicallydispatching the request to the identified at least one of the pluralityof remote devices complying with the selected at least one policy. 2.The computer-readable media of claim 1, where the media further holdsone or more instructions for: generating a result using the identifiedat least one of the plurality of remote devices complying with theselected at least one policy; and returning the result to the requestingdevice.
 3. The computer-readable media of claim 1, where the technicalcomputing environment is a MATLAB programming environment or aMATLAB-compatible programming environment.
 4. One or morecomputer-readable media holding executable instructions that whenexecuted on processing logic proactively scale distributed computingresources, the media holding one or more instructions for: providing aprocessing buffer in a distributed computing environment, where: thedistributed computing environment includes a technical computingenvironment, the processing buffer represents a determined amount ofexcess processing resources, and the excess processing resources provideadditional distributed processing capabilities to the distributedcomputing environment when the excess processing resources are engaged;measuring a processing load for the distributed computing environment;dynamically updating a model with the measured processing load, wherethe model: determines whether a size of the processing buffer isadequate, receives additional information, and includes one or morealgorithms that use the measured processing load and the additionalinformation to produce a result; evaluating the result to determinewhether: the size of the processing buffer is adequate, or the size ofthe processing buffer is inadequate, where an inadequate processingbuffer size indicates one of: the processing buffer size is smaller thandesired, or the processing buffer size is larger than desired; andincreasing the size of the processing buffer when the size of theprocessing buffer is smaller than desired by making additionaldistributed processing resources available to the distributed computingenvironment, or decreasing the size of the processing buffer when thesize of the processing buffer is larger than desired by making some ofthe distributed processing resources unavailable in the distributingcomputing environment.
 5. The computer-readable media of claim 4, wherethe additional information includes one or more of: historical data forthe distributed computing environment, rate-of-change information forthe distributed computing environment, event information for one or moreevents, where the events are internal or external to the distributedcomputing environment, and status information for devices in thedistributed computing network.
 6. The computer-readable media of claim4, where the processing buffer supports dynamically moving a processingjob among distributed processing resources while the job is running. 7.The computer-readable media of claim 4, where the processing buffersupports synchronized execution between two or more programs using thedistributed processing resources.
 8. One or more computer-readable mediaholding executable instructions that when executed on processing logicmaintain device independent state for a technical computing environmentassociated with a user, the media holding one or more instructions for:initiating a technical computing environment in response to aninstruction received from a user, where the technical computingenvironment is initiated on a first device associated with the user;performing a first operation on behalf of the user, where the firstoperation is performed using the technical computing environment on thefirst device; storing a state for the technical computing environment,where the state: represents a status of the technical computingenvironment with respect to the first device, and includes one or moreof: information about the first operation, a variable, data, an output,a sample time, an event, a configuration, a flag, an error message, adevice identifier, and an operating system identifier; receiving aninstruction from a second device, where the second device is associatedwith the user; loading the state when the instruction is received fromthe second device, providing access to the technical computingenvironment to the user via the second device, where the access reflectsthe state of the technical computing environment on the first device;and maintaining a synchronized state on the first device, where thesynchronized state: updates the state on the first device in response toinputs received from the user via the second device, updates a state onthe second device, where the updated state on the second device issubstantially the same with respect to the user as the updated state onthe first device, and provides the updated state to the user when theuser accesses the technical computing environment from the first device.9. The computer-readable media of claim 8, where the synchronized stateis maintained with a device providing a quick command window to a user.